分布式事务让所有暴富梦一夜破灭！

Posted 2021-03-31 架构师之路

可能你年轻时也曾做过这样一个美梦，银行转账出错，账户莫名多出巨款，神不知鬼不觉一夜暴富，第二天撒币逍遥快活，瞬间走上人生巅峰！

画外音：国外有个真事儿 ，去年8月，花旗银行帮客户还债，不慎多还5亿美元。重点是闹上法庭后银行败诉，对方最终无需退钱。

在 分布式事务 广泛应用前，我们或许真的有概率收到银行的错误转账（基于数据库常规事务的白日梦场景浮现）：

画外音： 不聊现实，只谈梦想。

第一步： 银行1同步调用远程接口，检查转出账户，结果调用接口超时导致主线程阻塞，勉强完成金额扣除；

第二步： 银行2对银行1的转入账户进行检查校验，完成金额增加；

第三步： 银行2突然因不可抗力宕机，无法返回“已到账”的结果给银行1，银行1接口响应异常，默认回滚第一步再次执行转账打款……

也就是说，如果银行系统仅仅利用事务，在极端情况下有可能出现纰漏。聪明的银行家们当然不会允许例外出现，于是他们四处打听，发现 分布式事务 正合心意。

分布式事务的核心定义是什么？

单机事务确保单数据源的数据一致性，分布式事务在分布式系统中 确保不同节点间的数据一致性。

让我们再回到梦中，银行经理花重金找到企鹅跳动的某程序员连夜上了分布式事务方案，于是转账操作变成了下述情况：

第一步： 转账事务开始前，中心化协调节 点（Coordinator）首先询问 银行1、银行2是否可以提交事务；

第二步：全票通过后，通知两家银行执行操作，因为事先确认过系统和物理存储环境状态，转账顺利完成，数据保持一致。

如果其中一家银行不同意提交事务，那么此次事务作废。以上就是 经典的分布式事务解决方案 2PC（两阶段提交） ，采用强一致性、中心化的原子提交协议，核心在于，只要有一个参与者投票选择放弃(abort)事务，则事务必须被放弃。 

并且，两阶段提交协议很依赖日志，只要存储介质不出问题，两阶段协议就能最终达到一致的状态（成功或者回滚）。也就是说，到这 梦基本就碎了 ！要么转账成功，要么回滚到未转账。

分布式事务真的无懈可击吗？

分布式事务在特定场景下会非常复杂，2PC只是通过增加 Coordinator 和2个阶段的处理流程，来确保分布式系统中的数据一致性，显然这种方案在某些异常情况下并不是完美的。

因此，3PC、TCC、SAGAS、Seata 等分布式事务解决方案不断涌现， 最终采用哪种方案，需要根据公司具体业务情况以及团队情况决定，没有标准答案。

结合你工作中接触的业务场景，你会采用何种分布式事务方案？如何落地 高可用、高并发的分布式事务架构？ 前58技术委员会主席孙玄打造的《百万年薪架构师必备能力—万亿级企业分布式事务多场景多维度架构设计的全攻略实践》在线专栏课。 3 大篇章 12 模块 干货课程， 限时特价 9.8。

课题 ：万亿级企业分布式事务多场景多维度架构设计的全攻略实践

讲师 ：孙玄

时间 ：3.15-3.17 三天速成，20:00开始

费用 ： 9.8 （原价 499 ， 粉丝福利价9.8 ）

名额 ：200名，先到先得

如何参加？

扫码占位 ，限200名额， 请等待课程顾问通过

学习，永无止境，愿大家早日财富自由。

阅读原文 ，了解更多。