分布式事务1理论篇

很久没写过了，写这个系列是因为工作中常年碰到。

先介绍下理论
再介绍下支付宝常用的DTX和XTC我看看我挑一个讲讲
再介绍下业内我知道的常用的几个实时的方案，毕竟大家其实不会去用阿里的技术，阿里技术也不是标杆
最后说下笔者所在的业务线常用的方案

分布式事务目前已知的解法都是无限降低出问题的可能性，但其实没有根治的方案。另外所有的解决方案你会发现一个问题：问题出概率越低的方案，系统性能越差，运维成本就越高。出概率高的方案，系统性能约好，运维成本越低。所以在实际实施过程中，一定要根据自己的业务场景来选择，不要过分追求系统稳定性和数据的准确性，这会付出极大的代价和成本。

笔者在阿里，负责国际事业部线上的电子商务的资金流。此类问题非常常见。
比如：一次线上用户钱包支付行为，核心设计的领域有3个，
资产域：负责管理个人用户资产的，这里除了基于账务的做的资金资产，还有营销的券资产，升值还有卡资产（用户的信用卡，储蓄卡等）。
账务域：这个就好理解了，资产域基于账务域就能形成一个个人账务资产的模型。
清结算+网关域：放在一起来说吧，主要是负责和支付机构或者银行打交道，屏蔽掉外部机构复杂的交互流程。

一次支付行为分解成一下几个步骤：
1.指令到资产域，资产域定位具体用户，并准备调用下面2支撑域来完成这个业务操作。
2.资产调用账务，完成对个人账户的资产扣减。
3.资产域将指令发给清结算网关域，清结算网关收到后，准备好指令。（一般发送给机构是异步的，毕竟你想想如果每笔转账都收费，那肯定比较划算的做法是：先将今天的指令全部缓冲，然后再发给机构）。

这里的分布式事务就是 账务和清结算网关必需要一起成功。不能账务扣减了，但转账指令没有发给机构，或者转账指令发给机构了，但账务没扣减。

由此我们归纳出一个ACID理论：
Atomicity：原子性（要么全部执行，要么全部都不执行）
Consistency：一致性（数据库只有一个状态，不存在未确定状态）
Isolation：隔离性（事务之间互不干扰）
Durability： 永久性（事务一旦提交，数据库记录永久不变）这条纯属多余，这个都做不到那还搞什么。主要是上面3个问题要解开。

方案一：2PC俩阶段提交
这里首先要引入2个角色：协调者和参与者。

从方案名字就知道是分2阶段完成。
准备阶段：协调者询问所有参与者是否都做完了除提交外所有事情。
提交阶段：协调者在上面阶段收到所有肯定回答后，让所有参与者都提交。如果不是全部的肯定回答，就让所有参与者回滚。

问题：1.协调者是单点
     2.性能问题：我都不觉得这是个问题，你都决定要分布式事务了，还担心这玩意，后面只会更差，但还是有其它方案会比2PC更好，当然是牺牲某些特性的前提下。
     3.数据不一致：所以说吧，根本无法根治。这条明显就破坏了原子性原则。什么情况呢?就是在阶段2时候如果协调者发给参与者的通知丢了，比如网络问题是吧。针对这个问题其实最简单有效且成本低的方案（这里低成本是指对软件开发者来说），就是把这2个领域应用部署到一个机房，更夸张的是，部署到一个物理机上（针对集群，可以尽量让2个调用优先在一台机器上跑，这个可以做到的）。

方案二：3PC阶段提交
性能更差的来了，其实看完就知道还是会违反原子性，无非就是降低了发生问题的概率而已。这个方案我觉得在丧失了这么大性能，更可怕的是对代码维护成本更高，得到了这么点的提升稳定性的保障，还不如部署在一个机房性价比更高。放心，线上网络和机器没那么容易挂。

参与角色还是：协调者和参与者，当然为了解决单点问题，可以引入选举机制，但我觉得这不是重点。

分成了3个阶段：
canCommit:其实就是去预占资源，占不到就等着，或者退出。（等着或者退出没有强制规定，自己决定即可）。
preCommit:就是之前的准备阶段，完成了除事务提交外，所有的事情。
doCommit:提交事务。

引入超时机制：比如在参与者完成preCommit后，迟迟没有收到（具体多久一般自己定）doCommit信号，你就可以认为大家都完成了doCommit，那我还是doCommit吧。
引入了选举机制：前面解释过了

性能更差，但说白了，能提升多少成功率，我觉得性价比不高。

方案三：TCC
没有协调者和参与者这种概念，简化成了调用方和被调用方。

一阶段Try行为：
调用方会分别调用多个被调用方，只有当多个被调用方都返回成功的时候，才会执行confirm操作，否则就执行cancel，这个阶段其实就是一个检查资源和锁定资源的操作，在真正执行前的一个冻结操作。
二阶段Confirm行为：
使用预留的资源，完成真正的业务操作，要求Try成功Confirm一定也是要成功的。要是个别或者全部confirm失败了或者调用超时了，和try阶段不同的是在confirm阶段不会做回滚操作，而是将所有的confirm进行重试，如果超过重试次数，则必须告警通知人工进行处理。
二阶段Cancel行为：
这个阶段是释放预留资源的阶段，只有在try阶段失败或者异常的情况下才会执行cancel操作。而且这里只对try步骤中已经成功的被调用者进行cannel处理，同时这个步骤失败也会重试。
TCC是柔性事务，解决了2PC中全局资源锁定导致效率低下的问题。

好了上面全是理论，下