业务流程：
1个空卡槽，可以做为上阵将领。
将领有攻击和防御的数值，
运营过程中，网络环境不是很好的情况下，上阵没有成功，继续上阵另一个将领卡，或者同一个将领卡。
最后不是做了替换的动作，同一个部位上的卡牌的属性获得了叠加。
缺陷定向描述：
1个可以反复插槽的问题， 插槽后，卡片的属性可以反复的增加，根据描述Db上可见重复的叠加。
Db立即同步了数据（db在这里使用么，还是只是1次data的更新）？多少时间存一次。
细则分析：
收集的数据不多。
但可以判断为层级的上中下为，客户端，服务端，Db。客户端和服务端之间还有1个buffer处理缓存数据的，使用1个bufferBlock的类。下文暂称为cache层。
但是这部分存在了每次操作，服务器一个数值上的判断，是放在cache里验证的，Db是定期保存了一次。
服务器做了累加，也就是说这部分客户端缺少了1个判断。延迟大的情况下，可以先不修改客户端，可以一个粘包的测试。可以看下问题是不是会发生。
这个是一个页游的话，可以使用1个缓存的机制。
替换的流程是 a.1个取下之前的卡牌 b.变更数值到cache c.卡牌入包 d.判断数值e.换上最新的卡牌 f.背包内减去最新的卡牌 g.最新的卡牌进入卡插槽 h.数值起了变化。
在手动环节中就2步，数值是可以通过打开界面才更新的。在cache里就可以刷新上去。
服务器那边只需要验证卡牌入包后的判断数值，为什么不在服务器优先做修改，是因为按置顶向下的原则，可以先做客户端的保护。
在1个取下之前的卡牌，变更数值到cache，经常客户端的判断，不经过服务端的。当在客户端本地做了保护后，无论是取下在装上都需要判断1次，那么就算网络延迟下也基本解决了。但是不可避免的绕过模态的方式。
为什么不在服务端去增加1个累计的保护，先判断。因为需要考虑到一个按置顶向下，能上层解决的问题尽量放在上层。
服务器改了是安全了，但是我们有需要确保的是这部分的开销会复用几次，有没有其他地方会用到。
如果加了这段，对于其他用这套协议的模块会不会影响，一个保护语句，会带来多少的复杂程度。
end