Seata中lock_key里的数据什么场景下会有脏数据呢?(历史的没有被删掉) 比如seata服务被强杀?或者业务服务被强杀? 我们昨天遇到运维批量重启服务导致lock_key没有被正常清理,后续服务频繁get global lock失败进而产生了悬挂问题,怀疑是服务是被强杀的 而不是正常重启。兜底的目的是什么呢?认为这种无用的lock数据一直留着会影响正常业务是吗?是什么场景促使这么做呢?是社区提的需求嘛还是实际考虑到了这种情况呢?got it 除了强杀seata服务还有哪些场景会导致lock脏数据残留吗?
强杀有几率出现的,只要有lock没branch或对应的globalsession,放心删了,高版本1.5上会在2分10秒后兜底这种情况,这种无用lock会阻塞业务正常运转,需要兜底删除,以后不要强杀进程,file模式和未来的raft模式没有这种问题,断电,事务决议时还有分支正在注册,断电其实就是强杀一个道理的,二者概率都非常低。此答案整理自钉钉群“3群-Seata开源讨论群”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。