1、概述
1.1、ACID
Atomic(原子操作、全部执行或者失败回滚)
Consistency(一致性，事务提交后原有的规则和约束不被破坏，对于数据库来说，就是不违反主键约束等，对于业务层面来说，就是满足业务规则)
Isolation(隔离性，并发中的事务是相互隔离的，4种隔离级别为：读未提交、读已提交、可重复读、串行化，如果没有事务隔离，出现的异常对应为：更新丢失、脏读、不可重复读、幻读)
Durability(持久性，一旦提交，数据要持久化，系统崩溃重启后，数据不丢失)
1.2、2PC
OSI TP提出的一致性协议--2PC协议：
一阶段、事务管理器TM请求所有的资源管理器RM预提交(prepare)各自的事务分支(RM不能提交则返回失败)。
二阶段、事务管理器TM向所有RM发送提交(commit)事务(第一阶段所有RM返回成功情况下才能提交事务)或回滚事务分支的请求。
优点：简单易行
缺点：同步阻塞、TM单点故障、RM数据不一致问题
1.3、CAP和BASE原理
CAP：Consistency、Availability、Partition tolerance(分区容错性)
2000.7，Eric Brewer提出，一个分布式系统不可能同时满足CAP这三个基本需求，最多只能满足其中的两项。
BASE：Basically Available、Soft state、Eventually consistent(最终一致性)
Dan Pritchett提出，基于CAP定理逐步演化而来，核心思想是即使无法做到强一致性，但是每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
2、解决方案
2.1、TCC模式
Pat Helland 在2007年首次提出，2017年进一步更新，主要概念包括：Tentative Operation(请求)、Confirmation(确定)、Cancellation(关闭)。
TCC(Try-Confirm-Cancel)状态图如下：
<------Cancel-----
Initial State --------try---------> Reserved State --------confirm-------> Final State
<------Timeout-----
初始状态 接到Try请求时变为 Reserved状态，接到confirm请求变为 最终状态， 接到Cancel/Timeout 回到初始状态。
TCC与2PC：
TCC更好适应SOA架构的分布式场景，并规范2PC中的黑盒操作，委托给各个业务场景去实现，使得失败场景，可以通过手工等方式介入，TCC是实现最终一致性的分布式事务。
TCC开源框架
tcc-transaction、Hmily、ByteTCC、EasyTransaction等
2.2、SAGA模式
2.2.1、SAGA概述
1987年普林斯顿大学的Hector Garcaa-Molrna与Kenneth Salem提出了SAGA的事务模式。涉及概念，
LLT(Long Lived Transaction)：持有数据库资源相对较长的长活事务。如果一个LLT可以被拆解为一序列可以跟其他事务错开执行(interleaved with)的子事务，而且这些子事务保持自身的ACID特性，要么成功提交，要么可以通过补偿事务(compensating transaction)来进行恢复，从而达到最终一致性，那个这个LLT就可称为SAGA。
2015年Caitie McCaffrey及Kyle Kingsbury提出了Distributed Sagas模式，将SAGA应用到分布式系统中。该模式定义了SEC(Saga Execution Coordinator)以及TEC(Transaction Execution Coordinator)。
整个SEC的执行逻辑如下所示：
对于整个SEC，启动的时候为Saga start，中断的时候为Saga abort，执行完成的时候为Saga done。从上图可以看出，每次操作之前都会先log一下，另外还维护了一个变量i，用来控制SAGA的子事务是否执行完或者补偿完，然后结束整个流程。
Distributed Saga对正常请求及补偿请求有如下几点要求：
❑ 正常请求以及补偿请求都必须是幂等的。
❑ 补偿请求是commutative的，commutative在这里的意思是：如果一个正常请求在补偿请求之后到达，那么正常请求不应该被执行。
❑ 正常请求可以被中断（触发补偿请求），但是补偿请求必须执行完成，没有中断操作。
此后，cloudfoundry.com创始人、《POJOS IN ACTION》的作者Chris Richardson在2017年11月份的QCONSF会议中发表了名为《ACID Is So Yesterday:Maintaining Data Consistency with Sagas》的演讲，同时展示了使用Eventuate Tram Saga framework通过SAGA模式处理微服务中的分布式事务的方法。Chris Richardson在http://microservices.io/网站以及《Microservices Patterns:With examples in Java》中将SAGA模式列为微服务的模式之一。
Chris Richardson还提出了SAGA的两种协调方式，分别是Orchestration和Choreography。Orchestration通常翻译为编制，其字面意思为管弦乐编曲。管弦乐有一个指挥官来进行集中控制，这里引申为对分布式事务的调度及协调。Choreography通常翻译为编排，其字面意思为舞蹈中的编舞，舞者一般跟着音乐节奏做出相应的动作及舞步，这里引申为根据外部事件等进行相应反应。在实现过程中，Orchestration一般是通过BPM流程中心或类似的管理器来实现统一控制，而Choreography则一般是通过Event Driven的事件方式来进行触发执行其他服务的本地事务
2.2.2、SAGA与2PC
与2PC相比，SAGA与TCC通过牺牲ACID的部分特性来提升分布式事务的可用性。另外SAGA及TCC可以理解为是服务层面的事务模式，将分布式事务的控制由数据库事务层提升到服务层。
2.2.3、SAGA与TCC
SAGA与TCC最显著的区别在于TCC采用的是预留资源的方式，其状态里有个Reserved状态；而SAGA则没有这个预留资源的动作，事务直接提交，然后采取的是补偿事务的方式来进行撤回。与2PC相比，2PC采用事务prepare以及rollback动作，整个都在一个大事务中，而SAGA是将这些大事务拆分为一个个本地事务。
2.2.4、SAGA与ACID
SAGA模式不满足Isolation的特性，因为其将LLT划分为一个个本地事务，一旦本地事务提交，在整个SAGA执行完毕之前，中间如果有其他事务也访问到了共享资源，则会读到“未完成”的事务的数据。与TCC类似，SAGA不满足C特性，SAGA实现的是最终一致性，但是拆分出来的一个个本地事务则满足ACID特性。
2.2.5、SAGA开源框架
支持SAGA的有如下几个开源框架：
❑ Axon framework：是一款采用Java编写的、面向可伸缩及高性能的CQRS框架，该框架内置了SagaRepository、SagaManager、SagaStore等组件，对SAGA模式提供了原生的支持。
❑ Eventuate.io:eventuate-tram-sagas是Chris Richardson开源的一款为使用JDBC/JPA的微服务准备的SAGA框架。
❑ Narayana LRA:Narayana是jboss提供的一款分布式事务管理器，其中实现SAGA模式的事务管理器为Narayana LRA, LRA为Long Running Action的缩写。
❑ ServiceComb Saga：是华为于2017年7月份开源的一款基于SAGA模式的分布式事务框架，目前在Apache孵化中。
参考书籍：
《重新定义Spring Cloud实战》
《从Paxos到ZooKeeper分布式一致性原理与实践》