深入理解分布式事务

分布式事务产生场景：
传统项目中多数据源（实现通过分包名或注解）、微服务场景（不同服务之间的相互调用）

例如上图所示场景：用户在完成下单之后程序会做3件事情
1.订单服务对应的订单状态改变
2.订单服务远程调用会员服务使其余额减少，积分增加
3.订单服务远程调用商品服务使其对应的商品库存减少
因此不同的服务对应了不同事务。要想服务之间的事务同步，就需要借助分布式事务技术。

ACID性质

原子性（Atomicity）：事务作为一个整体被执行，包含在其中的对数据库的操作要么全部被执行，要么都不执行。
一致性（Consistency）：事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。
隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行。
持久性（Durability）：已被提交的事务对数据库的修改应该永久保存在数据库中。

事务隔离级别

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

隔离级别	说明
Read Uncommitted 读未提交	在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
Read Committed 读已提交	这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。
Repeatable Read 可重读	这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。
Serializable 串行化读	这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

• 脏读(Drity Read)：指一个事务中访问到了另外一个事务未提交的数据
• 不可重复读(Non-repeatable read)：一个事务内根据同一个条件对行记录进行多次查询，但是搜出来的结果却不一致
• 幻读(Phantom Read):一个事务内多次查询返回的结果集不一样（比如增加了或者减少了行记录）

Spring事务传播行为

事务传播行为指：事务方法嵌套事务方法时如何进行传播。Spring在TransactionDefinition接口中规定了7种类型的事务传播行为

传播行为	说明
PROPAGATION_REQUIRED	新建事务，如果当前存在事务，加入到这个事务中。(默认的)
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

CAP理论

C:Consistency,一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本。
A:Availability,可用性。每一次请求服务都会在有限的时间内处理完成并进行响应。
P: Partition tolerance,分区容忍性。尽管网络上有部分消息丢失，但系统仍然可继续工作。
一般来说，分布式系统中，P是必须要保证的，设计一个分布式框架，只能在C和A之间做取舍。

BASE理论

BASE理论是指，Basically Available（基本可用）、Soft-state（ 软状态/柔性事务）、Eventual Consistency（最终一致性）。是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。核心思想：即使无法做到强一致性，但每个业务根据自身的特点，采用适当的方式来使系统达到最终一致性。
1、基本可用：指分布式系统在出现故障的时候，允许损失部分可用性，保证核心可用。但不等价于不可用。比如：搜索引擎0.5秒返回查询结果，但由于故障，2秒响应查询结果；网页访问过大时，部分用户提供降级服务，等。
2、软状态：软状态是指允许系统存在中间状态，并且该中间状态不会影响系统整体可用性。即允许系统在不同节点间副本同步的时候存在延时。
3、最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态，不需要实时保证系统数据的强一致性。最终一致性是弱一致性的一种特殊情况。

BASE理论面向的是大型高可用可扩展的分布式系统，通过牺牲强一致性来获得可用性，只需保证最终一致性。ACID是传统数据库常用的概念设计，追求强一致性模型。

柔性事务与刚性事务

柔性事务满足BASE理论(基本可用、最终一致性)；刚性事务满足ACID理论

两阶段提交协议

第一阶段提交请求阶段
协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。
参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个"同意"消息；如果参与者节点的事务操作实际执行失败，则它返回一个"中止"消息。
有时候，第一阶段也被称作投票阶段，即各参与者投票是否要继续接下来的提交操作。

第二阶段提交执行阶段
成功
当协调者节点从所有参与者节点获得的相应消息都为"同意"时：
协调者节点向所有参与者节点发出"正式提交"的请求。
参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送"完成"消息。
协调者节点收到所有参与者节点反馈的"完成"消息后，完成事务。
失败
如果任一参与者节点在第一阶段返回的响应消息为"终止"，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
协调者节点向所有参与者节点发出"回滚操作"的请求。
参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
参与者节点向协调者节点发送"回滚完成"消息。
协调者节点收到所有参与者节点反馈的"回滚完成"消息后，取消事务。
有时候，第二阶段也被称作完成阶段，因为无论结果怎样，协调者都必须在此阶段结束当前事务。

三阶段提交协议

与两阶段提交不同的是，三阶段提交有两个改动点。
1、引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，在提交请求阶段后加了一个准备提交阶段。
◆由协调者发准备提交消息(Prepare to Commit)。
◆参与者收到该消息后写入运行记录(Log record)中，并回答确认消息ACK。

一、优点
三段提交协议的优点：能避免阻塞状态，在三段提交协议中，如果协调者在第二段之后失效，不会产生像2PC协议中可能出现的事务阻塞现象。因为下面两种状态至少存在一种：

1. 所有参与者都进入Prepare to Commit状态，事务可以安全地提交。因为所有参与者都回答了ACK确认消息。
2. 至少有一个参与者未进入Prepare to Commit状态，事务可以安全回滚。因为至少有一个参与者未回答ACK确认消息，则协调者也不会发出Globle-Commit命令。

二、缺点
三段提交协议缺点：虽能避免阻塞状态，但需要更多的通讯次数，实现比较复杂。因此实际应用较少。大多数使用一致性提交协议的系统都采用二阶段提交协议。

分布式事务解决方案

1. Jta+Atomikos
2. 2PC与3PC
3. LCN

LCN分布式事务协调框架

LCN并不生产事务，LCN只是本地事务的协调工

LCN命名由来：锁定事务单元（Lock）、确认事务模块状态(Confirm) 、通知事务(Notify)

核心步骤

• 创建事务组
  是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。
• 加入事务组
  添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息通知给TxManager的操作。
• 通知事务组
  是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager,TxManager将根据事务最终状态和事务组的信息来通知相应的参与模块提交或回滚事务，并返回结果给事务发起方。

LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作（重写datasource的提交事务；方法执行完成后并不会提交事务，而是等待协调者通知），该代理的连接将由LCN连接池管理。