前情提要：

由于回调节点随机，处理任务庞大而冗长，还可能造成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}

问题产生的因素：

1. 在更新时候，会行锁 id=1的行
2. name 是个二级索引，所以也会锁二级索引name更改前后的值对应的行
3. 由于乐观锁是在提交那一刻去锁定，会产生死锁
4. 节点众多，同时操作，不仅冲突大，并且会大量产生死锁
5. 由于冲突大，对数据库资源消耗严重，使得大量查询超时

解决方法

1. 删除name索引解决死锁
2. 使用redis的list，rpop和 lpush （redis操作内存单线程） 2.1. 利用调度调起一个节点定时扫描数据源（注意同一时刻只能有一个生产者），把数据放入list队头。 2.2 利用全部节点去redis的list队尾取数据，先进行乐观锁更新，再进行业务处理 。 2.3 取完退出，定时起消费调度（注意保持一个节点一个时刻保持唯一）

这样解决的问题

1. 各个节点根据性能均分任务量，降低我们kafka客户端本地缓存队列占用内存大小
2. 基本不会出现抢锁引发的重试。乐观锁日志由原本的10分钟40W到7000
3. 数据库压力基本不变，各节点CPU维持在50%以下