神一样的CAP理论被应用在何方？( 五 ) _CAP理论

分布式事务
在分布式系统中，要实现分布式事务，无外乎几种解决方案。方案各有不同，不过其实都是遵循 BASE 理论，是最终一致性模型：

两阶段提交(2PC)
补偿事务(TCC)
本地消息表
MQ 事务消息

①两阶段提交(2PC)
还有一个数据库的 XA 事务，不过目前在真正的互联网中实际的应用基本很少，两阶段提交就是使用 XA 原理。

文章插图

在 XA 协议中分为两阶段：

事务管理器要求每个涉及到事务的数据库预提交(Precommit)此操作，并反映是否可以提交。
事务协调器要求每个数据库提交数据，或者回滚数据。

说一下，为何在互联网的系统中没被改造过的两阶段提交基本很少被业界应用，最大的缺点就是同步阻塞问题。
在资源准备就绪之后，资源管理器中的资源就一直处于阻塞，直到提交完成之后，才进行资源释放。
这个在互联网高并发大数据的今天，两阶段的提交是不能满足现在互联网的发展。
还有就是两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可能。
例如：在第二阶段中，假设协调者发出了事务 Commit 的通知，但是因为网络问题该通知仅被一部分参与者所收到并执行了 Commit 操作，其余的参与者则因为没有收到通知一直处于阻塞状态，这时候就产生了数据的不一致性。
②补偿事务(TCC)
TCC 是服务化的两阶段编程模型，每个业务服务都必须实现 Try ， Confirm ， Cancel 三个方法，这三个方式可以对应到 SQL 事务中 Lock ， Commit ， Rollback 。

文章插图

相比两阶段提交， TCC 解决了几个问题：同步阻塞，引入了超时机制，超时后进行补偿，并不会像两阶段提交锁定了整个资源，将资源转换为业务逻辑形式，粒度变小。
因为有了补偿机制，可以由业务活动管理器进行控制，保证数据一致性。
Try 阶段：Try 只是一个初步的操作，进行初步的确认，它的主要职责是完成所有业务的检查，预留业务资源。
Confirm 阶段：Confirm 是在 Try 阶段检查执行完毕后，继续执行的确认操作，必须满足幂等性操作，如果 Confirm 中执行失败，会有事务协调器触发不断的执行，直到满足为止。
Cancel 是取消执行：在 Try 没通过并释放掉 Try 阶段预留的资源，也必须满足幂等性，跟 Confirm 一样有可能被不断执行。
一个下订单，生成订单扣库存的例子：

文章插图

接下来看看，我们的下单扣减库存的流程怎么加入 TCC：

文章插图

在 Try 的时候，会让库存服务预留 N 个库存给这个订单使用，让订单服务产生一个“未确认”订单，同时产生这两个预留的资源。
在 Confirm 的时候，会使用在 Try 预留的资源，在 TCC 事务机制中认为，如果在 Try 阶段能正常预留的资源，那么在 Confirm 一定能完整的提交。

文章插图

在 Try 的时候，有任务一方为执行失败，则会执行 Cancel 的接口操作，将在 Try 阶段预留的资源进行释放。
这个并不是重点要论 TCC 事务是怎么实现，重点还是讨论分布式事务在 CAP+BASE 理论的应用。
实现可以参考：
https://github.com/changmingxie/tcc-transaction ③本地消息表
本地消息表这个方案最初是 eBay 提出的， eBay 的完整方案：
https://queue.acm.org/detail.cfm?id=1394128