分布式事务，怎么感觉不需要那么复杂

[bleulucaswu]

最近了解了一下 saga, Orchestration-based sagas 这些设计，貌似看起来非常的复杂，但是我觉得分布式事务的问题很好解决才对

• 比如一个 task 需要 a 服务 insert mongo, b 服务 insert mysql ，必须两个都 insert 成功才算是 task 成功了。

• 那么我就用 c 来做统筹工作，c 向 a b 发 http 指示它们 insert, 如果 a b 都返回 200 ，那就算成功了

• 如果有任何一个 insert 失败，那就向失败的那个发送回退的 http 就好了啊，insert 的话就是 delete 啊

• 然后 a b c 我可以多部署几个拷贝来保证可用性，http blocking 的并发问题用 non-blocking 的比如 webflux 这类技术来解决

• 如果考虑一致性的问题，比如回退过程中哪个服务 down 掉，导致数据不一致。

  • 但是再怎么复杂的分布式事务的设计，发送回退的指令的时候也有可能出现未知情况啊

为啥我这样想，觉得分布式事务也不是啥复杂的东西呢。

[lovelylain]

事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ），你觉得按你的实现，还能叫事务吗？

[v2defe]

acid 的 i 没解决

[bleulucaswu]

@v2defe 可以给 modify 中的数据加个 flag, 在 submit 之前是不可视。

[546L5LiK6ZOt]

像楼主说的场景，如果只是考虑两个异构存储的数据一致性，直接用 DTS 就好了，更简单。

[NeroKamin]

不就跟 2pc 差不多吗

[bleulucaswu]

@546L5LiK6ZOt 那 Saga 这种啥情况会用呢，有相关的成熟的技术吗

[oneisall8955]

你考虑的只是插入，更新呢，涉及 N 个微服务呢？

[thinkershare]

分布式事务是个 CAP 不可能三角，Saga 要解决的问题问题是一个分布式的事务处理是一个状态机，存在很多中间状态转换。你要保证所有状态的最终一致性，负责状态的补偿本身就是很复杂的，这个逻辑需要一个容纳的位置，放在各个子服务中是不合适的，因此使用 Saga 模式来管理整个状态转换过程。

[potatowish]

如果回退也失败了呢，怎么保证一致性

[az467]

确实不复杂。

因为不管你怎么设计，
要么不正确，要么本质上是 2pc 的变种。

[rekulas]

多年的开发经验早告诉我,如果我觉得一件工作整个行业都设计的太过复杂,那一定是我自己还没能理解复杂性在哪里

[yidinghe]

@rekulas 直到我看到一篇新闻说 Oracle 员工爆料自家数据库的代码就是屎山

[me1onsoda]

真的有人用分布式事务吗？本来为了提高性能分了库，分布式事务性能一笔吊糟，整个系统复杂度直线上升

[notwaste]

OP 的这个思路属于 TCC 吧，需要多做回退操作，但是其实本质上也属于 2PC ，分布式事务其实是个泛化伪命题，就好像多线程事务一样，跨进程不就破坏了隔离性吗

[crackhopper]

我反正也是个分布式方面的外行，就随便说点自己想到的复杂性：
需要有除了操作以外的日志记录步骤，这样回退出问题可以检测到，并重新回退。然后加了这个步骤就成了 2pc 。
还有其他复杂的地方，比如每个 api 要保证幂等，api 之间的依赖。。。回滚过程中和其他事件的互斥，以及业务上怎么更好处理互斥，互斥带来的性能问题。然后就复杂了呗。本身锁的实现可能不复杂，怎么用锁才是复杂的根源。

[bleulucaswu]

@potatowish 回退失败这种事 只能用重试解决吧 或者增加 instance 数量 保证出问题的概率小店 我感觉难的就隔离性麻烦点

[luoqeng]

异步通信分布式没法判断失败，你不知道是进程被挂起，还是网络延迟了，或者执行成功返回成功的消息丢失。

[happyxhw101]

c 请求 a, b -> 因为网络阻塞触发超时 -> 失败回滚 -> 回滚成功 -> 网络阻塞解除，初始的请求执行成功

所以有一种是基于 “可靠消息+本地消息表“ 的分布式事务解决方案

[luoqeng]

https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/lecture-12-distributed-transaction/12.1

[rekulas]

@yidinghe 这是两回事，哪怕你花几十亿重构一个新版本也会非常复杂，20 年后又是一坨新的山

[Chinsung]

回滚失败了呢？一个成功一个失败的话在整个回滚执行完之前可见性怎么保证呢？大部分方案都有所舍弃，你这种不就是究极简化版的 TCC 里把 T 都去掉了，这玩意没那么复杂但是要是真的有那么简单的话，也不会值得那么多讨论了

[546L5LiK6ZOt]

@bleulucaswu 各大云厂商都有成熟的 DTS 服务，开源的有 canal 。saga 我觉得可能在用不了类似 binlog 这种主从同步方式的场景下会有用吧。

[fuleigang]

这种主要麻烦的就是实际业务中涉及可能五六个，七八个系统，每个系统内部的业务也会涉及多张表，多个业务活动