目录
1、概念
2、分布式事务实现方式
2.1、2PC
2.2、Paxos
2.3、Raft
2.4、Zab
3、分布式事务解决方案
3.1、TCC（LCN框架）
3.2、LCN（LCN框架）
3.3、TXC（LCN框架）
3.4、基于可靠消息服务的分布式事务
分布式事务分类
刚性分布式事务：强一致性、XA模型
柔性分布式事务：最终一致性、cap、base理论
ACID，关系数据库的ACID模型拥有 高一致性 + 可用性 很难进行分区：
Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。Consistency一致性：在事务开始或结束时，数据库应该在一致状态。Isolation隔离层：事务将假定只有它自己在操作数据库，彼此不知晓。Durability持久化：一旦事务完成，就不能返回。BASE，BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically Available 基本可用：支持分区失败(e.g. sharding碎片划分数据库)Soft state 软状态：状态可以有一段时间不同步，异步。Eventually consistent 最终一致：最终数据是一致的就可以了，而不是时时高一致。CAP，分布式领域CAP理论：
Consistency(一致性)：数据一致更新，所有数据变动都是同步的Availability(可用性)：好的响应性能Partition tolerance(分区容忍性)：可靠性定理：任何分布式系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。
跨数据库两段提交事务：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，JavaEE中的JTA事务可以支持2PC。因为2PC是反模式，尽量不要使用2PC，使用BASE来回避。
第一阶段
提交事务请求：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。执行事务：各个参与者节点执行事务操作。并将Undo和Redo信息记入事务日志中。各参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行。第二阶段
执行事务提交：假如协调者从所有参与者获得的响应都为Yes，那么就执行事务提交，协调者向所有参与者节点发出Commit请求参与者提交事务：参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源,并向协调者发送Ack消息完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务中断事务
假如任何一个参与者反馈给协调者No响应，或者在等待超时之后，协调者没有收到所有参与者的响应，那么就会中断事务
发送回滚请求：协调者向所有参与者发送Rollback请求事务回滚：参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，完成回滚之后释放在整个事务执行期间占用的资源，并向协调者发送Ack消息，协调者接收到所有的参与者反馈的Ack消息后，完成事务中断优缺点
二阶段提交协议的整个过程就是这样，这种先请求后提交的方式，能够保证所有节点在进行事务处理过程中保持原子性，进行统一的提交或回滚，可以看作是一个强一致性的算法。那我们就来思考一下，它有哪些优点，以及会带来什么问题。
优点：简单好用，实现方便。缺点：同步阻塞，单点问题，还是会有数据不一致的情况出现。同步阻塞：在二阶段提交事务的过程中，所有参与该事务操作的逻辑都处于阻塞状态，各个参与者在等待其他参与者的响应过程中，无法做其他的操作。单点问题：在二阶段提交协议中，协调者这个角色是很重要的，一旦协调者挂掉，将导致整个提交流程无法运转，若是在第二阶段协调者挂掉，参与者将一直处于锁定事务资源的状态，无法继续完成事务操作。数据不一致：若是在第二阶段，协调者在向所有参与者发送commit请求时，由于局部网络的故障，只有部分参与者受到commit请求，提交事务，这样没有受到commit请求的就没有提交事务，出现了数据不一致的情况。https://blog.csdn.net/Dopamy_BusyMonkey/article/details/107709465
https://blog.csdn.net/Dopamy_BusyMonkey/article/details/107711800
https://blog.csdn.net/Dopamy_BusyMonkey/article/details/90612899
(Try-Confirm-Cancel)补偿模式（最终一致性）TCC模型完全交由业务实现、每个子业务都需要实现TCC接口：try：尝试执行业务，完成所有业务检查、预留必要的业务资源；confirm：真正执行业务、不再做业务检查；cancel：释放try阶段预留的业务资源。
该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。该模式对有无本地事务控制都可以支持使用面广。数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。
该模式对代码的嵌入性为低。该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据，然后保存执行的SQL快走信息和创建锁。当需要回滚的时候就采用这些记录数据回滚数据库，目前锁实现依赖redis分布式锁控制。
该模式同样对代码的嵌入性低。该模式仅限于对支持SQL方式的模块支持。该模式由于每次执行SQL之前需要先查询影响数据，因此相比LCN模式消耗资源与时间要多。该模式不会占用数据库的连接资源。DTP模型（全局事务、强一致性）
全局事务基于DTP模型实现。DTP是由X/Open组织提出的一种分布式事务模型——X/Open Distributed Transaction Processing Reference Model。它规定了要实现分布式事务，需要三种角色：
AP：Application 应用系统 ，它就是我们开发的业务系统，在我们开发的过程中，可以使用资源管理器提供的事务接口来实现分布式事务。TM：Transaction Manager 事务管理器，分布式事务的实现由事务管理器来完成，它会提供分布式事务的操作接口供我们的业务系统调用。这些接口称为TX接口。事务管理器还管理着所有的资源管理器，通过它们提供的XA接口来同一调度这些资源管理器，以实现分布式事务。DTP只是一套实现分布式事务的规范，并没有定义具体如何实现分布式事务，TM可以采用2PC、3PC、Paxos等协议实现分布式事务。RM：Resource Manager 资源管理器，能够提供数据服务的对象都可以是资源管理器，比如：数据库、消息中间件、缓存等。大部分场景下，数据库即为分布式事务中的资源管理器。资源管理器能够提供单数据库的事务能力，它们通过XA接口，将本数据库的提交、回滚等能力提供给事务管理器调用，以帮助事务管理器实现分布式的事务管理。XA是DTP模型定义的接口，用于向事务管理器提供该资源管理器(该数据库)的提交、回滚等能力。DTP只是一套实现分布式事务的规范，RM具体的实现是由数据库厂商来完成的。有没有基于DTP模型的分布式事务中间件？
DTP模型有啥优缺点？
rocketmq
最大努力通知（定期校对）
