浅析分布式事务

当谈到事务时，大家立即会想到事务的ACID（Atomicity, Consistency, Isolation, Durability），它是在数据库事务的上下文中提出的数据库事务需要满足的特性。传统的单机应用中，事务的管理都委托给数据库，只要应用将相关的操作放置在一个数据库事务中，数据库就会按照自己的一致性和隔离性设置来处理事务中的操作。有一种特例是，当系统有多个数据库时，需要应用系统按照两阶段提交协议（2PC，XA事务是一种典型的实现）来提交事务，保证数据在多个数据库中的数据一致性。

那么在分布式系统中，一个服务不可避免的会与其它的服务进行交互，当然在拆分服务时，我们应该优先把原子性的操作封装在同一个服务中，以降低系统管理事务一致性的复杂度。理想很美好，但是现实很骨感，当事务不可避免的跨多个服务时，都有哪些理论和实践指导我们因地制宜的采取合适的方案去管理它呢？

分布式事务理论-CAP定理

CAP定理又被叫作布鲁尔定理。C（Consistency），对于分布式系统而言，对于数据分布在不同节点上的数据来说，如果某个节点的数据更新了，其它节点都能读到最新的数据，那么就称为强一致性；A（Availability），非故障节点在合理的时间返回正确的响应；P（Partition tolerance），当某些节点出现故障后，系统正常提供服务的能力。CAP理论中，分布式系统不可能同时满足三个特性，我们必须根据系统的特性做出权衡。一般来说，我们选择CA而放弃P，分布式系统中不做分区，是达不到高可用的。对于CP来说，在可用性上妥协，追求一致性和分区容错性，Zookeeper其实就是追求的强一致；对于AP来说，放弃一致性(这里说的一致性是强一致性)，追求分区容错性和可用性，这是很多分布式系统设计时的选择。

分布式事务理论-BASE

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对CAP中AP的一个扩展。

基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

软状态:允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。

分布式事务解决方案

2PC&3PC, 与分布式数据库中事务管理方式相同，2PC是指两阶段提交，事务管理器会对不同节点发起预提交请求，待所有节点返回成功后，会正式提交请求。三阶段提交是针对两阶段缺点而设计的改进型，引入超时机制，在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的。

TCC（Try-Confirm-Cancel），TCC事务机制相比于上面的事务管理机制，进行了优化，解决了协调者单点，由主业务方发起并完成这个业务活动。Try阶段尝试执行业务，完成所有业务检查，预留必须的业务资源；Confirm阶段确认执行业务；Cancel取消执行业务，释放Try阶段预留的业务资源。

本地消息表，本地消息表这个方案最初是ebay提出的，此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。

MQ事务，在RocketMQ中实现了分布式事务，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ内部，下面简单介绍一下MQ事务，基本流程如下：拿到消息的地址, 执行本地事务, 通过第一阶段拿到的地址去访问消息，并修改状态，消息接受者就能使用这个消息。

Saga事务，Saga其实是30年前的一篇数据库论文里提到的一个概念。在论文中一个Saga事务就是一个长期运行的事务，这个事务是由多个本地事务所组成， 每个本地事务有相应的执行模块和补偿模块，当saga事务中的任意一个本地事务出错了， 可以通过调用相关事务对应的补偿方法恢复，达到事务的最终一致性。