+
 新版
2020-11-18 07:29
作者还是一贯有些随意,第二个依赖的坐标kafka写成了kafa。
2020-11-18 11:37
了解我.... 我下次版本改一下
2020-11-18 11:44
哈哈,跟大赋老相识了,还是了解的,没有贬义,就是觉得我们可以做到更严谨一点,包括代码的空格,空行什么的,单词拼写。
2020-11-17 21:21
现在的版本使用mapper的insert(),有没有什么办法返回主键?
2020-11-18 11:38
主键自动包含在对象里了
2020-11-17 15:02
支持一个,从方案到实现做的真快
2020-11-17 15:42
看看有啥漏洞没?
2020-11-17 16:10
心有余而力不足啊,最近在做项目,等以后有时间再来跑跑看。不过两个关键点如果你都注意到就应该问题不大,一个是事务重入问题,在分布式事务进行或回滚期间,必须有个柔性锁标记告知其它事务不要覆盖当前事务中的数据。一个是网线在任意时候断掉都不影响最终数据一致性,这个包括手工恢复。当然硬件损坏这种不算。
2020-11-17 17:08
必须有个柔性锁标记告知其它事务不要覆盖当前事务中的数据,这个咋搞?那岂不是阻止其他正常业务执行了?
2020-11-18 00:19
seata是这样做的,在提交过程中记录每个SQL访问了哪些表格的哪些记录,然后以这个记录作为锁, 下一次事务提交之前,也要记录每个SQL访问了哪些表格的哪些记录,并和现有的锁对比,如果有重复记录说明事务重入了,就不提交第二个事务,这样可以保证隔离性,这是个业务无侵入的方案。我的方案和seata类似,但只支持实体CRUD,不支持SQl,靠ORM工具来生成每个实体ID的锁记录。你用saga方案,可以在事务一头一尾检查和设立一个业务相关的标记,比方说最外层锁定订单,最里层的事务提交时解锁标记,或回滚到最外层事务时解锁标记,这样可以保证事务不重入。
以上三种方式都是柔性事务,不保证第三方工具无视锁记录直接修改数据库这种情况,但这种情况一般不会出现,除非编程出错。
2020-11-18 11:40
嗯,我个人倾向”事务一头一尾检查和设立一个业务相关的标记“,我看微服务模式里里的saga也提到了这种方式,这需要开发人员更多的考虑
回复 @
{{emojiItem.symbol}}
返回顶部
顶部