分布式事务 可靠消息最终一致性 ，最大努力通知 seata TXLCN

介绍；
一、事务的ACID原则
　　数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。

原子性：操作这些指令时，要么全部执行成功，要么全部不执行。只要其中一个指令执行失败，所有的指令都执行失败，数据进行回滚，回到执行指令前的数据状态。
一致性：事务的执行使数据从一个状态转换为另一个状态，但是对于整个数据的完整性保持稳定。
隔离性：在该事务执行的过程中，无论发生的任何数据的改变都应该只存在于该事务之中，对外界不存在任何影响。只有在事务确定正确提交之后，才会显示该事务对数据的改变。其他事务才能获取到这些改变后的数据。
持久性：当事务正确完成后，它对于数据的改变是永久性的。
二 ，CAP理论
CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍 性。
下边我们分别来解释： 为了方便对CAP理论的理解，我们结合电商系统中的一些业务场景来理解CAP。 如下图，是商品信息管理的执行流程：

整体执行流程如下：
1、商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）
2、主数据库向商品服务响应写入成功。
3、商品服务请求从数据库读取商品信息。
C - Consistency： 一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都 是最新的状态。
上图中，商品信息的读写要满足一致性就是要实现如下目标：
1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。
2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。
如何实现一致性？
1、写入主数据库后要将数据同步到从数据库。
2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功 后，向从数据库查询到旧的数据。
分布式系统一致性的特点：
1、由于存在数据同步的过程，写操作的响应会有一定的延迟。
2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。
3、如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。
A - Availability ：
可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。
上图中，商品信息读取满足可用性就是要实现如下目标：
1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。
2、从数据库不允许出现响应超时或响应错误。
如何实现可用性？
1、写入主数据库后要将数据同步到从数据库。
2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
3、即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照 约定返回一个默认信息，但不能返回错误或响应超时。
分布式系统可用性的特点：
1、 所有请求都有响应，且不会出现响应超时或响应错误。
P - Partition tolerance ：
通常分布式系统的各各结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间 通信失败，此时仍可对外提供服务，这叫分区容忍性。
上图中，商品信息读写满足分区容忍性就是要实现如下目标：
1、主数据库向从数据库同步数据失败不影响读写操作。
2、其一个结点挂掉不影响另一个结点对外提供服务。
如何实现分区容忍性？
1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现 松耦合
2、添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。
分布式分区容忍性的特点：
1、分区容忍性分是布式系统具备的基本能力。
2.1.2CAP组合方式；
1、上边商品管理的例子是否同时具备 CAP呢？
在所有分布式事务场景中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的。
比如：
下图满足了P即表示实现分区容忍：

本图分区容忍的含义是：
1）主数据库通过网络向从数据同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。
2）当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。
3）其一个结点挂掉不影响另一个结点对外提供服务。 如果要实现C则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据则需要将从数据库数 据锁定，待同步完成后解锁，如果同步失败从数据库要返回错误信息或超时信息。 如果要实现A则必须保证数据可用性，不管任何时候都可以向从数据查询数据，则不会响应超时或返回错误信息。 通过分析发现在满足P的前提下C和A存在矛盾性。

2、CAP有哪些组合方式呢？
所以在生产中对分布式事务处理时要根据需求来确定满足CAP的哪两个方面。
1）AP： 放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。
例如： 上边的商品管理，完全可以实现AP，前提是只要用户可以接受所查询的到数据在一定时间内不是最新的即可。 通常实现AP都会保证最终一致性，后面讲的BASE理论就是根据AP来扩展的，一些业务场景 比如：订单退款，今 日退款成功，明日账户到账，只要用户可以接受在一定时间内到账即可。
2）CP： 放弃可用性，追求一致性和分区容错性，我们的zookeeper其实就是追求的强一致，又比如跨行转账，一次转账请 求要等待双方银行系统都完成整个事务才算完成。
3）CA： 放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统 将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA
。 上边的商品管理，如果要实现CA则架构如下：

主数据库和从数据库中间不再进行数据同步，数据库可以响应每次的查询请求，通过事务隔离级别实现每个查询请 求都可以返回最新的数据。

2.1.3 总结
通过上面我们已经学习了CAP理论的相关知识，CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足 一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作 为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的 集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99…%），并要达到良 好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。
2.2.BASE理论
1、理解强一致性和最终一致性
CAP理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍 性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP即舍弃一致性，保证可用性和分区容忍 性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要 一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和CAP中的一致性不同，CAP中的一致性要求 在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结 点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。
2、Base理论介绍 BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩 写。BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证 核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为“柔 性事务”。
基本可用:分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如，电商网站交易付款出 现问题了，商品依然可以正常浏览。 软状态:由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用 性，如订单的"支付中"、“数据同步中”等状态，待数据最终一致后状态改为“成功”状态。 最终一致:最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变 为“支付成功”或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。

三 分布式事务；
所谓分布式事务，软禁系统由原来的单体应用转变成分布式应用；

分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操 作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务，例如用户注册送积分 事务、创建订单减库存事务，银行转账事务等都是分布式事务。
1.2 分布式事务实现方案
　　现在的分布式事务实现方案有多种，有些已经被淘汰，如基于XA的两段式提交、TCC解决方案，还有本地消息表、MQ事务消息，还有一些开源的事务中间件，如LCN、GTS
　　1.2.1 基于XA的两阶段提交方案
1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事 务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者 发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操 作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

XA 它包含两个部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如 Oracle、DB2 这些商业数据库都实现了 XA 接口，而事务管理器作为全局的协调者，负责各个本地资源的提交和回滚。

两阶段提交方案应用非常广泛，几乎所有商业OLTP (On-Line Transaction Processing)数据库都支持XA协议。但是两阶段提交方案开发复杂、锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。
　　
1.2.22 TCC解决方案
　　TCC方案在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。

Try 阶段主要是对业务系统做检测及资源预留，完成业务的准备工作。

Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。

微服务倡导服务的轻量化、易部署，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。
　　1.2.3 本地消息事务表（异步确保）
　　 本地消息表eaby 如图；
　　
我们首先需要在本地数据新建一张本地消息表，然后我们必须还要一个MQ（不一定是mq，但必须是类似的中间件）。

消息表怎么创建呢？这个表应该包括这些字段： id, biz_id, biz_type, msg, msg_result, msg_desc,atime,try_count。分别表示uuid，业务id，业务类型，消息内容，消息结果（成功或失败），消息描述，创建时间，重试次数， 其中biz_id，msg_desc字段是可选的。

实现思路为：

A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；
接着 A 系统将这个消息发送到 MQ 中去；
B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；
B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；
如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；
这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。
　　这个方案严重依赖于数据库的消息表来管理事务，这样在高并发的情况下难以扩展，同时要在数据库中额外添加一个与实际业务无关的消息表来实现分布式事务，繁琐
　　1.2.4 MQ事务消息
　　 直接基于 MQ 来实现事务，不再用本地的消息表。有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。
　　 四，分布式事务中间件解决
　　 分布式事务中间件其本身并不创建事务，而是基于对本地事务的协调从而达到事务一致性的效果。典型代表有：阿里的GTS（https://www.aliyun.com/aliware/txc）、开源应用LCN。

其实现原理如下：
　　
LCN分布式事务框架
　　1、LCN框架的由来
　　在设计框架之初的1.0 ~ 2.0的版本时，框架设计的步骤是如下的，各取其首字母得来的LCN命名。

锁定事务单元（lock）、确认事务模块状态(confirm)、通知事务(notify)

2、LCN框架相关资料
tx-lcn官方地址：https://www.txlcn.org/
tx-lcn Github地址：https://github.com/codingapi/tx-lcn
tx-lcn服务下载地址：https://pan.baidu.com/s/1cLKAeE#list/path=%2F
tx-lcn服务源码地址：https://github.com/codingapi/tx-lcn/tree/master/tx-manager

3、LCN框架核心执行步骤
创建事务组：是指在事务发起方开始执行业务代码之前先调用TxManager创建事务组对象，然后拿到事务标示GroupId的过程。

添加事务组：添加事务组是指参与方在执行完业务方法以后，将该模块的事务信息添加通知给TxManager的操作。

关闭事务组：是指在发起方执行完业务代码以后，将发起方执行结果状态通知给TxManager的动作。当执行完关闭事务组的方法以后，TxManager将根据事务组信息来通知相应的参与模块提交或回滚事务。

	如图所示，如果调用顺序为A{业务A，B{业务B}}这种A包含B的方式，
	那么正常调用时序图为：

如果B发生异常，那么时序图为：

　　如果调用顺序为A{业务A}，B{业务B}这种A先于B的方式，那么B发生异常时的时序图为；
　　
Seata 方案；
Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务 达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务，下 图是全局事务与分支事务的关系图：

与 传统2PC 的模型类似，Seata定义了3个组件来协议分布式事务的处理过程：

Transaction Coordinator (TC)：
事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运 行状态，接收TM指令发起全局事务的提交与回滚，负责与RM通信协调各各分支事务的提交或回滚。
Transaction Manager ™：
事务管理器，TM需要嵌入应用程序中工作，它负责开启一个全局事务，并最终 向TC发起全局提交或全局回滚的指令。
Resource Manager (RM)：
控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分 支（本地）事务的提交和回滚。

具体的执行流程如下：
1. 用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
2. 用户服务的 RM 向 TC 注册 分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局 事务的管辖。
3. 用户服务执行分支事务，向用户表插入一条记录。
4. 逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC 注册分支事 务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。
5. 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
6. 用户服务分支事务执行完毕。
7. TM 向 TC 发起针对 XID 的全局提交或回滚决议。
8. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

Seata执行流程;
1.正常提交流程；

2.回滚流程；

说明；
1、每个RM使用DataSourceProxy连接数据库，其目的是使用ConnectionProxy，使用数据源和数据连接代理的目 的就是在第一阶段将undo_log和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有 undo_log。
2、在第一阶段undo_log中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完成就已经将分 支事务提交，也就释放了锁资源。
3、TM开启全局事务开始，将XID全局事务id放在事务上下文中，通过feign调用也将XID传入下游分支事务，每个 分支事务将自己的Branch ID分支事务ID与XID关联。
4、第二阶段全局事务提交，TC会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各 各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成。
5、第二阶段全局事务回滚，TC会通知各各分支参与者回滚分支事务，通过 XID 和 Branch ID 找到相应的回滚日 志，通过回滚日志生成反向的 SQL 并执行，以完成分支事务回滚到之前的状态，如果回滚失败则会重试回滚操 作。

.RocketMQ事务消息方案；
RocketMQ 事务消息设计则主要是为了解决 Producer 端的消息发送与本地事务执行的原子性问题，RocketMQ 的 设计中 broker 与 producer 端的双向通信能力，使得 broker 天生可以作为一个事务协调者存在；而 RocketMQ 本身提供的存储机制为事务消息提供了持久化能力；RocketMQ 的高可用机制以及可靠消息设计则为事务消息在系 统发生异常时依然能够保证达成事务的最终一致性。

	在RocketMQ 4.3后实现了完整的事务消息，实际上其实是对本地消息表的一个封装，将本地消息表移动到了MQ 内部，解决 Producer 端的消息发送与本地事务执行的原子性问题。

执行流程如下：
Producer 即MQ发送方。
MQ订阅方即消息消费方。
1、Producer 发送事务消息 Producer （MQ发送方）发送事务消息至MQ Server，MQ Server将消息状态标记为Prepared（预备状态），注 意此时这条消息消费者（MQ订阅方）是无法消费到的。 本例中，Producer 发送 ”增加积分消息“ 到MQ Server。
2、MQ Server回应消息发送成功 MQ Server接收到Producer 发送给的消息则回应发送成功表示MQ已接收到消息。
3、Producer 执行本地事务 Producer 端执行业务代码逻辑，通过本地数据库事务控制，Producer 执行添加用户操作
4、消息投递 若Producer 本地事务执行成功则自动向MQServer发送commit消息，MQ Server接收到commit消息后将”增加积 分消息“ 状态标记为可消费，此时MQ订阅 即正常消费消息；
若Producer 本地事务执行失败则自动向MQServer发送rollback消息，MQ Server接收到rollback消息后 将删 除”增加积分消息“ 。 MQ订阅方（积分服务）消费消息，消费成功则向MQ回应ack，否则将重复接收消息。这里ack默认自动回应，即 程序执行正常则自动回应ack。
5、事务回查 如果执行Producer端本地事务过程中，执行端挂掉，或者超时，MQ Server将会不停的询问同组的其他 Producer 来获取事务执行状态，这个过程叫事务回查。
MQ Server会根据事务回查结果来决定是否投递消息。 以上主干流程已由RocketMQ实现，对用户侧来说，用户需要分别实现本地事务执行以及本地事务回查方法，因此 只需关注本地事务的执行状态即可。

RoacketMQ提供RocketMQLocalTransactionListener接口：

public interface RocketMQLocalTransactionListener { 
/** ‐ 发送prepare消息成功此方法被回调，该方法用于执行本地事务 ‐ 
@param msg 回传的消息，利用transactionId即可获取到该消息的唯一Id 
‐ @param arg 调用send方法时传递的参数，当send时候若有额外的参数可以传递到send方法中，这里能获取到
 ‐ @return 返回事务状态，COMMIT：提交 ROLLBACK：回滚 UNKNOW：回调 
 */
RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg); 

/** ‐ @param msg 通过获取transactionId来判断这条消息的本地事务执行状态
 ‐ @return 返回事务状态，COMMIT：提交 ROLLBACK：回滚 UNKNOW：回调
  */

RocketMQLocalTransactionState checkLocalTransaction(Message msg); 

}