分布式事务

理论基础

CAP定理

• 一致性（Consistency) $\to$ 所有节点在同一时间具有相同的数据
• 可用性（Availability）$\to$ 保证每个请求不管成功或者失败都有响应
• 分隔容忍（Partition tolerance） $\to$ 系统中任意信息的丢失或失败不会影响系统的继续运作

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。

ACID模型

• 原子性（Atomicity，或称不可分割性）
• 一致性（Consistency）
• 隔离性（Isolation，又称独立性）
• 持久性（Durability）

BASE模型

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

分布式事务

两阶段提交（2PC）

1. client发起一个开始请求到TC
2. TC先将消息写到本地日志，之后向所有的Si发起消息。以支付宝转账到余额宝为例，TC给A的prepare消息是通知支付宝数据库相应账目扣款1万，TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行任务前需要先写本地日志，主要是为了故障后恢复用，本地日志起到现实生活中凭证 的效果，如果没有本地日志（凭证），出问题容易死无对证
3. Si收到消息后，执行具体本机事务，但不会进行commit，如果成功返回，不成功返回。同理，返回前都应把要返回的消息写到日志里，当作凭证
4. TC收集所有执行器返回的消息，如果所有执行器都返回yes，那么给所有执行器发生送commit消息，执行器收到commit后执行本地事务的commit操作；如果有任一个执行器返回no，那么给所有执行器发送abort消息，执行器收到abort消息后执行事务abort操作

PS： TC或Si把发送或接收到的消息先写到日志里，主要是为了故障后恢复用。如某一Si从故障中恢复后，先检查本机的日志，如果已收到，则提交，如果则回滚。如果是，则再向TC询问一下，确定下一步。如果什么都没有，则很可能在阶段Si就崩溃了，因此需要回滚

优点

尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）

缺点

实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

补偿事务（TCC）

• Try 阶段主要是对业务系统做检测及资源预留
• Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

优点

跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点

缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

Sagas模式