在上线后跟踪mysql的某操作历史表,发现部分操作纪律未在上一条的基础上进行更改。该操作是在分布式服务中,多服务并行运行,但均置于事务中并用for update排它锁锁住的,理论上说不应该出现并发修改。
整理了一下mysql的for update排它锁能实现的条件:1、必须置于事务中,事务要能生效,特别是spring中事务方法必须是public,且必须是由类外调用该事务方法。2、for update的查询语句必须规范,要么查询条件是主键,要么查询条件要走索引,至于最终是锁行还是锁表都有可能。3、如果有读写分离中间件,必须保证for update到主库,因为一般从库都是read-only(for update语句在read-only环境中会报错)
线上环境均满足以上条件,且做测试发现能排它锁运行正常。最终找到原因为一傻逼在线上分布式环境中开启了mybatis的二级缓存。。。
记一次mysql for update失效原因排查
最新推荐文章于 2023-06-10 15:29:03 发布
在分布式服务中,尽管使用了forupdate排它锁和事务处理,但出现部分操作记录未按预期更新的情况。排查后发现罪魁祸首是MyBatis的二级缓存,其在多服务并行运行时导致数据一致性问题。确保满足forupdate锁的条件,并关闭二级缓存后,问题得到解决。
摘要由CSDN通过智能技术生成