背包系统设计问题

概述 

由于业务需要，灵活的，交易等原因，目前我们将很多不属于背包的功能放入背包，起初感觉这样省了不少事情，很多东西的获取直接走背包就好，不用添加任何协议。

问题

1.定点恢复的功能，需要再玩家上号时全部更新掉，而且无法知道客户端什么时候需要真正的数据，造成服务器在登陆前期、和特定恢复时间点出现大量无效的处理流程。

2.另外就是时间的问题，有些几分钟恢复的功能，使用道具（道具不会出现分数），可能出现一定的误差，时间需要精确把握（比如还差一秒恢复一滴，那个就需要将时间做特殊处理）。

3.无法重用已有的数据（count = 0的数据），由于，许多模块，根据新的DbId去处理流程，导致，原本相同ItemId的物品不能被重用，数据库，一直在产生无效数据，特别是我们将词条相关的也放入背包，当词条被销毁时，对于背包来说，就是数量没有了，而实际的情况时，这个词条不能再被用了，面对类似这种情况，加了许多特殊处理。

4.背包模块越来越臃肿，常见的游戏一般会有背包的数量限制，如果背包融合了许多其它的功能，就很难再做限制。

物品堆叠

在这个问题上，我们支持三种：可堆叠；不可堆叠，新数据固定数量不可堆叠

背包数据过多问题

由于背包数据太多，查证后，发现是配表方式有问题，对于一个道具需要加1000个来表示，某一属性的提升值，这个本身就是“不可堆叠的”，由于这类东西存在单独升级的流程，又不能合在一起，我们的策略是，当加的时候，如果是一起加的，直接将数量固定下来，后面不允许改变，这个就是上面说的 “新数据固定数量不可堆叠”。我想这样只是减少一部分集中添加的数据量，其实根本的解决办法，就是将这类移除背包，另开系统处理。

物品大类小类

由于没有将物品的 大类、小类放入数据库，所以获取数据时，只能先将数据全部加入内存，分类获取。

无法分类加载解决办法 

1.将ItemId 和 MainType, SubType 导入数据库表，在查询时，连表查询。

这样做的话 存在需要维护数据库表的负担

2.根据配表，获取ItemId 去数据库 IN 先关物品

可能导致发送的IN数据过多，很多时候大部分都找不到