大家 Springcloud 中有用分布式事务吗，用的是什么？

• 資深大佬 : huntcool001

  @huntcool001
  Seata 是用二阶段提交(2PC)的吗？

• 資深大佬 : user8341

  看你们的业务要求和场景，尽量设计上避免使用分布式事务

• 資深大佬 : hun2008hun

  业务上应该尽量避免分布式事务，服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临麻烦的分布式事务问题

• 資深大佬 : leafre

  3L 4L 说的很对,分布式事务是一个就算解决也很麻烦的问题,能绕过就绕过

• 資深大佬 : wysnylc

  不是尽量避免，而是要想尽办法避免使用分布式事务。嗯，搞了将近 5 年的微服务了，目前还没有遇到不能避免的情况。

• 資深大佬 : xuanbg

  尽量不要用分布式事务吧，太复杂了没必要

• 資深大佬 : IDAEngine

  分布式事务现在太依赖人工，支付宝对个账都安排了上万人

• 資深大佬 : IDAEngine

  人工补偿，累死你

• 資深大佬 : kerro1990

  不要考虑用什么技术,先安排一组人对账再说

• 資深大佬 : seanxx

  尽量不要用分布式事务

  补偿+最终一致

• 資深大佬 : Jooooooooo

  @IDAEngine 哥，你好，意思是说 oceanbase 达到宣传性能的前提是有万人对账团队吗？我一直以为阿里的产品早就实现了接近完美的分布式解决方案
• 資深大佬 : lpts007

  @IDAEngine 这么傲娇的吗？万人对账

• 資深大佬 : lionseun

  虽然搞了这么多年微服务，但是到现在也没用过分布式事务，我一直觉得这俩根本不应该一起出现。

• 資深大佬 : limuyan44

  我们用的是微服务设计模式中的 saga 模式，事件驱动的方式。

• 資深大佬 : threeEggs123

  @IDAEngine 支付宝都万人对账，那工行建行怎么整

• 資深大佬 : lori01

  @IDAEngine 能稍微具体解释一下吗？谢谢

• 資深大佬 : warush

  @lori01 他们估计都是 Oracle

• 資深大佬 : IDAEngine

  @warush 出问题概率大，需要大量人工纠错

• 資深大佬 : IDAEngine

  @lpts007 参考下微信支付架构，比较有参考意义

• 資深大佬 : IDAEngine

  分布式事务 本质上就是在套娃 有异议的吗？

• 資深大佬 : xiangyuecn

  @lori01 这几大行核心业务目前都是 IBM 小型机..

• 資深大佬 : huntcool001

  @huntcool001 一般都是 IBM DB2 或 Oracle，阿里那一套弄下来成本更高，另外就是没油水可以捞，谁会大力去推

• 資深大佬 : kerro1990

  利用可靠消息异步确保。

• 資深大佬 : jaylee4869

  没用过，用的 中间状态+补偿解决的