这是一个创建于 589 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近了解了一下 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 掉，导致数据不一致。
- 但是再怎么复杂的分布式事务的设计，发送回退的指令的时候也有可能出现未知情况啊
为啥我这样想，觉得分布式事务也不是啥复杂的东西呢。
 | 1 lovelylain 2024-02-28 20:07:33 +08:00 via Android 事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ），你觉得按你的实现，还能叫事务吗？ |
 | 2 v2defe 2024-02-28 20:08:14 +08:00 via Android acid 的 i 没解决 |
 | 3 bleulucaswu OP @v2defe 可以给 modify 中的数据加个 flag, 在 submit 之前是不可视。 |
 | 4 546L5LiK6ZOt 2024-02-28 21:55:40 +08:00 像楼主说的场景，如果只是考虑两个异构存储的数据一致性，直接用 DTS 就好了，更简单。 |
 | 5 NeroKamin 2024-02-28 22:05:26 +08:00 不就跟 2pc 差不多吗 |
| 6 bleulucaswu OP @546L5LiK6ZOt 那 Saga 这种啥情况会用呢，有相关的成熟的技术吗 |
 | 7 itechify PRO 你考虑的只是插入，更新呢，涉及 N 个微服务呢？ |
 | 8 thinkershare 2024-02-28 23:09:51 +08:00 分布式事务是个 CAP 不可能三角，Saga 要解决的问题问题是一个分布式的事务处理是一个状态机，存在很多中间状态转换。你要保证所有状态的最终一致性，负责状态的补偿本身就是很复杂的，这个逻辑需要一个容纳的位置，放在各个子服务中是不合适的，因此使用 Saga 模式来管理整个状态转换过程。 |
 | 9 potatowish 2024-02-28 23:10:30 +08:00 via iPhone  2 如果回退也失败了呢，怎么保证一致性 |
 | 10 az467 2024-02-28 23:34:28 +08:00 via Android 1 确实不复杂。 因为不管你怎么设计， 要么不正确，要么本质上是 2pc 的变种。 |
 | 11 rekulas 2024-02-28 23:56:14 +08:00 1 多年的开发经验早告诉我,如果我觉得一件工作整个行业都设计的太过复杂,那一定是我自己还没能理解复杂性在哪里 |
 | 13 me1onsoda 2024-02-29 09:15:33 +08:00 2 真的有人用分布式事务吗？本来为了提高性能分了库，分布式事务性能一笔吊糟，整个系统复杂度直线上升 |
 | 14 notwaste 2024-02-29 10:34:27 +08:00 OP 的这个思路属于 TCC 吧，需要多做回退操作，但是其实本质上也属于 2PC ，分布式事务其实是个泛化伪命题，就好像多线程事务一样，跨进程不就破坏了隔离性吗 |
 | 15 crackhopper 2024-02-29 10:37:00 +08:00 我反正也是个分布式方面的外行，就随便说点自己想到的复杂性： 需要有除了操作以外的日志记录步骤，这样回退出问题可以检测到，并重新回退。然后加了这个步骤就成了 2pc 。 还有其他复杂的地方，比如每个 api 要保证幂等，api 之间的依赖。。。回滚过程中和其他事件的互斥，以及业务上怎么更好处理互斥，互斥带来的性能问题。然后就复杂了呗。本身锁的实现可能不复杂，怎么用锁才是复杂的根源。 |
| 16 bleulucaswu OP @potatowish 回退失败这种事 只能用重试解决吧 或者增加 instance 数量 保证出问题的概率小店 我感觉难的就隔离性麻烦点 |
 | 17 luoqeng 2024-02-29 12:30:04 +08:00 1 异步通信分布式没法判断失败，你不知道是进程被挂起，还是网络延迟了，或者执行成功返回成功的消息丢失。 |
 | 18 happyxhw101 2024-02-29 12:47:47 +08:00 c 请求 a, b -> 因为网络阻塞触发超时 -> 失败回滚 -> 回滚成功 -> 网络阻塞解除，初始的请求执行成功 所以有一种是基于 “可靠消息+本地消息表“ 的分布式事务解决方案 |
| 19 luoqeng 2024-02-29 14:50:08 +08:00 |
 | 21 Chinsung 2024-02-29 18:02:25 +08:00 回滚失败了呢？一个成功一个失败的话在整个回滚执行完之前可见性怎么保证呢？大部分方案都有所舍弃，你这种不就是究极简化版的 TCC 里把 T 都去掉了，这玩意没那么复杂但是要是真的有那么简单的话，也不会值得那么多讨论了 |
| 22 546L5LiK6ZOt 2024-02-29 18:35:11 +08:00 @bleulucaswu 各大云厂商都有成熟的 DTS 服务，开源的有 canal 。saga 我觉得可能在用不了类似 binlog 这种主从同步方式的场景下会有用吧。 |
 | 23 fuleigang 2024-04-08 17:20:27 +08:00 这种主要麻烦的就是实际业务中涉及可能五六个，七八个系统，每个系统内部的业务也会涉及多张表，多个业务活动 |
Select Language