这是一个创建于 1949 天前的主题，其中的信息可能已经有所发展或是发生改变。
25 条回复 2020-10-20 18:06:08 +08:00
 | 1 huntcool001 2020 年 10 月 19 日 肯定用啊. 不然微服务跨库查询就没办法了. 我们用的是 Seata. |
 | 2 9LCRwvU14033RHJo 2020 年 10 月 19 日 @huntcool001 Seata 是用二阶段提交(2PC)的吗？ |
 | 3 hun2008hun 2020 年 10 月 19 日  3 看你们的业务要求和场景，尽量设计上避免使用分布式事务 |
 | 4 leafre 2020 年 10 月 19 日 业务上应该尽量避免分布式事务，服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临麻烦的分布式事务问题 |
 | 5 wysnylc 2020 年 10 月 19 日 3L 4L 说的很对,分布式事务是一个就算解决也很麻烦的问题,能绕过就绕过 |
 | 6 xuanbg 2020 年 10 月 19 日 不是尽量避免，而是要想尽办法避免使用分布式事务。嗯，搞了将近 5 年的微服务了，目前还没有遇到不能避免的情况。 |
 | 7 IDAEngine 2020 年 10 月 19 日 via iPhone 尽量不要用分布式事务吧，太复杂了没必要 |
| 8 IDAEngine 2020 年 10 月 19 日 via iPhone 分布式事务现在太依赖人工，支付宝对个账都安排了上万人 |
 | 9 kerro1990 2020 年 10 月 19 日 人工补偿，累死你 |
 | 10 seanxx 2020 年 10 月 19 日 不要考虑用什么技术,先安排一组人对账再说 |
 | 11 Jooooooooo 2020 年 10 月 19 日 尽量不要用分布式事务 补偿+最终一致 |
 | 12 lpts007 2020 年 10 月 20 日 via Android @IDAEngine 哥，你好，意思是说 oceanbase 达到宣传性能的前提是有万人对账团队吗？我一直以为阿里的产品早就实现了接近完美的分布式解决方案 |
 | 14 limuyan44 2020 年 10 月 20 日 虽然搞了这么多年微服务，但是到现在也没用过分布式事务，我一直觉得这俩根本不应该一起出现。 |
 | 15 threeEggs123 2020 年 10 月 20 日 via Android 我们用的是微服务设计模式中的 saga 模式，事件驱动的方式。 |
 | 21 xiangyuecn 2020 年 10 月 20 日 分布式事务 本质上就是在套娃 有异议的吗？ |
| 22 huntcool001 2020 年 10 月 20 日 @lori01 这几大行核心业务目前都是 IBM 小型机.. |
| 23 kerro1990 2020 年 10 月 20 日 @huntcool001 一般都是 IBM DB2 或 Oracle，阿里那一套弄下来成本更高，另外就是没油水可以捞，谁会大力去推 |
 | 24 lavvrence 2020 年 10 月 20 日 利用可靠消息异步确保。 |
 | 25 JaeCoding 2020 年 10 月 20 日 没用过，用的 中间状态+补偿解决的 |
Select Language