分布式事务与最终一致性

事务

事务是什么：做为单个逻辑单元执行的一组操作，要么全成功，要么都失败。
事务4个特性：原子性，一致性，隔离性，持久性。

分布式事务

分布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现由很多种，最具代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。

XA协议

包含两种实现
两阶段提交（2PC）：第一阶段提交事务请求，第二阶段执行事务提交（统一提交或者回滚）。

• 优点：原理简单，实现方便。
• 缺点：同步阻塞对资源锁定时间长，单点问题协调者的可用性在至关重要，协调者发送完commit之前自身崩溃造成有些节点commit有些没有而数据不一致，太过保守。
  三阶段提交（3PC）：第一阶段CanCommit，第二阶段PreCommit（事务操作在此处执行但不提交），第三阶段doCommit。
• 优点：相对于二阶段提交，最大的优势降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
• 缺点：参与者收到PreCommit消息之后，再出现网络问题，参与者超时收不到协调者消息会继续提交事务造成数据不一致。

参考：《从Paxos到ZooKeeper-分布式一致性原理与实践》第2章

TCC方案

TCC方案是二阶段提交的一种改进。将整个业务逻辑的每个分支显示的分成了Try、Confirm、Cancel三个操作。Try完成业务的准备工作，Confirm完成业务的提交，Cancel完成事务的回滚。

TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
缺点集中表现在以下两个方面：

• 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
• 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等。

上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。

基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。
基本思路：是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。
本质上是：将分布式事务转换成两个本地事务，然后依靠下游业务的重试机制达到最终一致性。

最终一致性

最终一致性描述的是分布式系统中，当系统在数据一致的状态执行更新之后，也应该保持一致的状态。具体实现中可以表现为过程中异步软一致性，但结果要强一致性。
相关理论包括：
ACID事务特性理论：数据库事务的基本要素，原子性，一致性，隔离性，持久性
CAP分布式理论：分布式系统中一致性，可用性，分区容错性最多可以同时实现两个，不可能三者兼得
BASE理论：Basic Availability业务基本可用，Soft state柔性状态，Eventual consistency最终一致性

最终一致性常用的方法

单数据库

通过数据的事务的特性可以很好的解决，并且此时是强一致性。

多数据库

针对多数据库事务可以根据二阶段提交协议，可以通过Spring + Atomikos + JTA进行实现。

Altomikos是一款Java平台事务管理器，它是封装了XA特性的一个中间价。
JTA（Java Transaction API）Java事务编程接口，为JEE平台提供分布式事务服务。

基于事务性消息队列的最终一致性

第一步保证本地事务和提交消息都执行成功，第二步消息队列来投递进行处理，并重试机制保证执行成功。仅适用于第一阶段成功，第二阶段必须成功的场景。

基于消息队列和定时补偿机制的最终一致性

相对于上一种依赖消息中间件自身的重试逻辑，而是通过单独的补偿任务机制来实现。其中补偿任务机制又可通过多种方式实现包括：

• 定时任务补偿：通过定时任务跟进后续任务，根据不同的状态表确定下一步的操作，来保证业务最终执行成功。缺点是可能设计很多后台服务，维护起来比较麻烦。
• 消息补偿：通过消息中间件返回结果触发后续的任务。

引入异步回调机制

通过类似回调通知的逻辑，通知调用者执行结果。

类似Double Check的确认机制