项目乐观锁引发的问题

前情提要:

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

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值