请教后端们关于分布式事务的实践

[cinlen]

大约有这几个问题：

1. 当前使用/曾经使用的分布式事务的方案是什么？
2. 你觉得比较好的方案是哪种？（综合考虑 “对架构复杂度提升”，”对代码可读性的影响“，“对程序员写代码的心智负担提升”等等）
3. 综合下来，做这件事划算吗？是让你更轻松了，还是让你更累了？
4. 如果你加入了一家新公司，当前业务需要引入分布式事务，你会选择哪种方案？

我看过网络上的理论文，但希望得到有真实实践过的后端同学们的分享，而不是全文背诵网络上的文章，这样就没有意义了。

[giantreaper0]

我司用的就是 seata 的 AT + TCC ，用他是因为这个项目最初就有而且是老前辈们手写出来的，已经屎山了。总结下来就是能不用就不用分布式事务，只要模块拆分的够好绝大部分情况是不需要的，少部分需要的用消息队列做

[giantreaper0]

- 简单介绍一下我对 AT 的理解，就是在这个模式下，你等于无数据库的原生事务去执行，也就是你的每一条 sql 都会立即落库，如果发生了回滚，seata 有一份修改前的镜像用来回滚。
- 这时候你就会问那回滚的时候被别的业务修改了怎么办，seata 会根据主键有一个全局锁，如果多个分布式（加粗）事务同时修改同一行能正常阻塞等待，因此这里就是有坑，代码那么多总会有只开了本地事务没开分布式事务的情况，这时候 seata 就会回滚失败，然后人工处理
- 同时我司某些表还存在近似于全表删除的业务，这种情况下有可能甚至把 seata-server 直接打挂

[guanhui07]

TCC DTM 应该也是补偿机制吧

[v2exgo]

@giantreaper0 #22 感谢，这是实践才能踩坑到的

[v2exgo]

@giantreaper0 #22 另外 TCC 跟 AT 能混着用么，TCC 不是需要自己手写补偿代码么

[giantreaper0]

@v2exgo 可以的，我个人的理解 AT 就是 seata 帮你实现的通用型 TCC

[giantreaper0]

我司的 TCC 实践有
1. 用 TCC 实现库存的增减、锁库
2. 有一些用数据库实现的任务队列，然后有定时任务轮训查询去执行任务会有一些数据其实还在全局事务进行中，但由于没有本地事务会导致也能查出来，这时候就需要利用 TCC ，在二阶段提交的时候将 "global_tx_commited" 设置为 1 ，定时任务只查询 global_tx_commited = 1 的任务

[nicoley]

@giantreaper0 涨姿势了，感谢分享～