项目乐观锁引发的问题

前情提要：

由于回调节点随机，处理任务庞大而冗长，还可能造成kafka本地实现的队列占用内存过高。造成节点频繁宕机。
故需要切小回调数据文件，再进行各节点均分处理数据。分摊压力
由于回调数据量过大，需要分批保存到数据库再去处理，处理完成移入备份表。

大致过程如下

1. 先查出A表状态为0的500条数据（按入表时间排序）
2. 遍历改状态为1并根据版本号乐观锁更新
3. 如果返回码是1，说明该节点操作成功
4. 如果失败，不重复抢，直接进行下一条
5. 进行数据处理，然后数据移到备份表
6. 移到备份表步骤： 1. 根据id查，2插入备份表，3删除A表该条数据

生产出现的问题：

问题1： 备份表有很多状态为0的初始数据

解决方法：最终还是一位经验丰富的大神给出原因：

1. 在我们第六步移动到备份表时候 查询会默认从库查询
2. 由于我们有100+个节点并发操作 所以数据库主从同步就会有一定的时间差
3. 所以查出的是从库A表该id未同步状态的数据信息，移动到备份表！

问题2：乐观锁冲突过大产生的问题

出现大量死锁，项目频繁查询超时，节点宕机，CPU飙升至150%

问题分析
乐观锁这个版本上了生产以后，由于更新语句中

UPDATE TABLE SET name='1',version=#{version} WHERE id=1 AND version=#{version}