1处缺陷的分析过程（重复叠加了属性的）

jiazurongyu

业务流程：
1个空卡槽，可以做为上阵将领。
将领有攻击和防御的数值，
运营过程中，网络环境不是很好的情况下，上阵没有成功，继续上阵另一个将领卡，或者同一个将领卡。
最后不是做了替换的动作，同一个部位上的卡牌的属性获得了叠加。

缺陷定向描述：
1个可以反复插槽的问题， 插槽后，卡片的属性可以反复的增加，Db上可见重复的叠加。
Db立即同步了数据？先标记在?

细则分析：
收集的数据不多。
但可以判断为层级的上中下为，客户端，服务端，Db。
但是这部分存在了每次操作，服务器一个数值上的判断，是放在cache里验证的，Db是定期保存了一次。
服务器做了累加，也就是说这部分客户端缺少了1个判断。延迟大的情况下，可以先不修改客户端，可以一个粘包的测试。可以看下问题是不是会发生。

替换是1个取下之前的卡牌，变更数值到cache，卡牌入包，判断数值，换上最新的卡牌，背包内减去最新的卡牌，最新的卡牌进入卡插槽。
服务器那边只需要验证卡牌入包后的判断数值，为什么不在服务器优先做修改，是因为按置顶向下的原则，可以先做客户端的保护。
在1个取下之前的卡牌，变更数值到cache，经常客户端的判断，不经过服务端的。当在客户端本地做了保护后，无论是取下在装上都需要判断1次，那么就算网络延迟下也基本解决了。但是不可避免的绕过模态的方式。

为什么不在服务端去增加1个累计的保护，先判断。因为需要考虑到一个按置顶向下，能上层解决的问题尽量放在上层。
服务器改了是安全了，但是我们有需要确保的是这部分的开销会复用几次，有没有其他地方会用到。
如果加了这段，对于其他用这套协议的模块会不会影响，一个保护语句，会带来多少的复杂程度。
end

maxwell12

1、客户端做限制，没用，很容易绕过客户端的操作禁止限制。胖客户端不能解决所有的问题。
2、服务器端的基本消息处理上，替换将领不应该有问题。服务器端程序如果基本消息流程有问题，在网络良好的情况下，也能出这个bug。
3、因为网络消息延迟造成这种现象，检查时序性问题。不允许或严格检查多线程处理流程是否存在时序问题。