分布式事务让所有暴富梦一夜破灭！
可能你年轻时也曾做过这样一个美梦，银行转账出错，账户莫名多出巨款，神不知鬼不觉一夜暴富，第二天撒币逍遥快活，瞬间走上人生巅峰！
画外音：国外有个真事儿
，去年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
）
标签:
