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