从0-1事务-柔性事务-分布式事务_柔性事务和分布式事务

事务的概念：
事务从数据库引申而来，事务即一组原子性的sql查询。
ACID（别名：酸碱平衡理论）：

• 事物的原子性（A: Atomicity）：一个事务必须被设为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中的一部分操作，这就是事务的原子性。
• 一致性（C: Consistency）：数据库总是从一个一致性的状态转换到另一个一致性的状态。
• 事务隔离性（I: Isolation）：一个事务所做的修改在最终提交以前，其他事务是不可见的。
• 持久性（D: Durability）：持久化策略。
  具有ACID的特性的数据库支持强一致性，强一致性代表数据库本身不会出现不一致，每个事务是原子的，或者成功或者失败，事物间是隔离的，互相完全不影响，而且最终状态是持久落盘的，因此，数据库会从一个明确的状态到另外一个明确的状态，中间的临时状态是不会出现的，如果出现也会及时的自动的修复，因此是强一致的。
  补充知识点：
  
  
  
  

数据库的引擎是Inoodb，是如何保证数据一致性的呢？具体的可以参考这篇文章

事务的ACID是通过InnoDB日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的，持久性通过redo log（重做日志）来实现，原子性和一致性通过Undo log来实现。UndoLog的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为UndoLog）。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。
和Undo Log相反，RedoLog记录的是新数据的备份。在事务提交前，只要将RedoLog持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是RedoLog已经持久化。系统可以根据RedoLog的内容，将所有数据恢复到最新的状态。

为什么着重关注一致性？（生活场景）
一致性对于订单支付，同步数据，缓存数据，以及公司对外口径，夫妻对外口径都有着重大意义，一旦不一致的情况发生，客诉，公司形象，夫妻不愉快等问题。

对于一致性是所有系统应该着重关注的思考点，怎么理解强一致性、单调一致性和最终一致性？

强一致性
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。如果是在分布式环境场景下，根据 CAP 理论，这种实现需要牺牲可用性。






简要归纳总结：
强一致性------主要发生在ACID（原子性、一致性、隔离性、持久性）关系型数据库下。
单调一致性-----单调读一致性和单调写一致性
最终一致性-----主要发生在分布式环境下BASE理论

分布式理论

• 一致性，可用性，容错性------其实考察CAP原理。
• 基本可用性、软状态、最终一致性-----------BASE理论

CAP理论：

• C：Consistency，一致性, 数据一致更新，所有数据变动都是同步的
• A：Availability，可用性, 好的响应性能，完全的可用性指的是在任何故障模型下，服务都会在有限的时间处理响应
• P：Partition tolerance，分区容错性，可靠性
  理论证明，任何分布式系统只可同时满足二点，没法三者兼顾。关系型数据库由于关系型数据库是单节点的，因此，不具有分区容错性，但是具有一致性和可用性，而分布式的服务化系统都需要满足分区容错性，那么我们必须在一致性和可用性中进行权衡，具体表现在服务化系统处理的异常请求在某一个时间段内可能是不完全的，但是经过自动的或者手工的补偿后，达到了最终的一致性

BASE理论
BASE模型与ACID模型截然不同，满足CAP理论，通过牺牲强一致性，获得可用性，一般应用在服务化系统的应用层或者大数据处理系统，通过达到最终一致性来尽量满足业务的绝大部分需求

• BA：Basically Available，基本可用
• S：Soft State，软状态，状态可以有一段时间不同步
• E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致

小结：

• 如果资金不是问题，可以考虑升级数据库硬件配置，达到满足单机ACID事务原则。
• 如果没有足够的资金，可以对廉价硬件运行的开源关系型数据库（例如：Mysql）进行分片，将相关的数据分到数据库的同一个片，仍然能够使用关系型数据库保证事务
• 如果业务规则限制，无法将相关的数据分到同一个片，就需要实现最终一致性，通过记录事务的软状态（中间状态、临时状态），一旦处于不一致，可以通过系统自动化或者人工干预来修复不一致的情况

柔性事务

• 所谓柔性事务是相对强制锁表的刚性事务而言。流程入下：服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。
  缺点是业务侵入性太强，还要补偿操作，缺乏普遍性，没法大规模推广
  通常说的柔性事务分为：两阶段型，补偿型，异步确保型，最大努力通知型几种。
• 两阶段型：分布式事务两阶段提交，对应技术上的XA、JTA/JTS.这是分布式环境下事务处理的典型模式。
• 补偿型：TCC型事务（Try/Confirm/Cancel）可以归为补偿型。
  
• 异步确保型：
  通过将一系列同步的事务操作变为基于消息执行的异步操作，避免了分布式事务中的同步阻塞操作的影响。
  
• 最大努力通知型（多次尝试）
  这是分布式事务中要求最低的一种，也可以通过消息中间件实现，与前面异步确保型操作不同的一点是，在消息由MQ Server投递到消费者后，允许在达到最大重试次数之后正常结束事务。

分布式事务

• 什么是分布式事务：
  分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
  从上面本地事务来看，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。
• service应用多个节点
  随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。
  
• resource多个节点
  同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。
  

• 什么是著名的拜占庭将军问题？
  在很久很久以前，拜占庭是东罗马帝国的首都。那个时候罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信使传递消息。在打仗的时候，拜占庭军队内所有将军必需达成一致的共识，才能更好地赢得胜利。但是，在军队内有可能存有叛徒，扰乱将军们的决定。这时候，在已知有成员不可靠的情况下，其余忠诚的将军需要在不受叛徒或间谍的影响下达成一致的协议。莱斯利·兰伯特（ Leslie Lamport ）通过这个比喻，表达了计算机网络中所存在的一致性问题。这个问题被称为拜占庭将军问题。

分布式事务解决方案
1）分布式事务处理模型（DTS）（TX协议、XA协议，2PC，3PC，TCC协议）

国际开放标准组织Open Group定义了DTS（分布式事务处理模型），模型中包含4个角色：应用程序、事务管理器、资源管理器、通信资源管理器四部分。事务处理器是统管全局的管理者，资源处理器和通信资源处理器是事务的参与者。
J2EE规范也包含此分布式事务处理模型的规范，并在所有的AppServer中进行实现，J2EE规范中定义了TX协议和XA协议，TX协议定义应用程序与事务管理器之间的接口，而XA协议定义了事务管理器与资源处理器之间的接口，在过去，大家使用AppServer，例如：Websphere、Weblogic、Jboss等配置数据源的时候会看见类似XADatasource的数据源，这就是实现了DTS的关系型数据库的数据源。企业级开发JEE中，关系型数据库、JMS服务扮演资源管理器的角色，而EJB容器则扮演事务管理器的角色。
下面我们就介绍两阶段提交协议、三阶段提交协议以及阿里巴巴提出的TCC，它们都是根据DTS这一思想演变出来的。

• Two/Three Phase Commit两阶段提交协议（XA协议就是根据两阶段提交来保证事务的完整性，并实现分布式服务化的强一致性。）

• 两阶段提交协议把分布式事务分成两个过程，一个是准备阶段，一个是提交阶段，准备阶段和提交阶段都是由事务管理器发起的。
  

• 准备阶段（投票阶段）：

• 事务询问：协调者向参与者发起指令询问是否可以执行事务提交操作，并等待各参与者的响应
• 执行事务：各参与者执行事务操作，并将redo或者undo信息记入事务日志（这也是前面提起的Write-Ahead Log的一种）
• 各参与者向协调者反馈事务询问的响应：如果全反馈OK，则事务可以执行，否则不可以执行。

• 提交阶段：

• 执行事务提交：如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，那么就会执行事务提交操作。

• 发送提交请求：协调者向参与者发起commit请求
• 事务提交：参与者提交资源变更的事务，完成之后释放锁定的资源；
• 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送ACK信息。
• 完成事务：协调者接受到所有参与者反馈的ACK消息后，完成事务。

• 中断事务：假如任何一个参与者向协调者反馈了No响应，或者等待超时以后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

• 发送回滚请求：协调者向所有参与者节点发出rollback请求。
• 事务回滚：参与者接收到rollback请求后，会利用阶段一中记录的Undo信息来执行事务回滚操作，并完成回滚之后释放整个事务执行期间占用的资源。
• 反馈事务回滚结果：参与者完成事务回滚之后，向协调者发送Ack消息。
• 中断事务：协调者收到所有参与者反馈的Ack消息后，完成事务中断。
  
  小结：二阶段提交将一个事务处理分为了投票和执行两个阶段，其核心是对每个事务采用先尝试后提交的处理方式，因此也可以将二阶段提交看做一个强一致性的算法。
  缺点：、

• 阻塞：从上面的描述来看，对于任何一次指令必须收到明确的响应，才会继续做下一步，否则处于阻塞状态，占用的资源被一直锁定，不会被释放
• 单点故障：如果协调者宕机，参与者没有了协调者指挥，会一直阻塞，尽管可以通过选举新的协调者替代原有协调者，但是如果之前协调者在发送一个提交指令后宕机，而提交指令仅仅被一个参与者接受，并且参与者接收后也宕机，新上任的协调者无法处理这种情况
• 脑裂：协调者发送提交指令，有的参与者接收到执行了事务，有的参与者没有接收到事务，就没有执行事务，多个参与者之间是不一致的
• 容错机制不健全：如果参与者出现中断，协调者只能通过超时机制来判断是否中断事务，没有较为完善的容错机制。

总的来说，XA协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是其最大的弱点。

• 三阶段提交协议
  三阶段提交协议是两阶段提交协议的改进版本。它通过超时机制解决了阻塞的问题，并且把两个阶段增加为三个阶段

• 询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是还是不是，而不需要做真正的操作，这个阶段超时导致中止
• 准备阶段：如果在询问阶段所有的参与者都返回可以执行操作，协调者向参与者发送预执行请求，然后参与者写redo和undo日志，执行操作，但是不提交操作；如果在询问阶段任何参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这里的逻辑与两阶段提交协议的的准备阶段是相似的，这个阶段超时导致成功
• 提交阶段：如果每个参与者在准备阶段返回准备成功，也就是预留资源和执行操作成功，协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任何一个参与者返回准备失败，也就是预留资源或者执行操作失败，协调者向参与者发起中止指令，参与者取消已经变更的事务，执行undo日志，释放锁定的资源，这里的逻辑与两阶段提交协议的提交阶段一致

优点：

• 增加了一个询问阶段，询问阶段可以确保尽可能早的发现无法执行操作而需要中止的行为，但是它并不能发现所有的这种行为，只会减少这种情况的发生
• 在准备阶段以后，协调者和参与者执行的任务中都增加了超时，一旦超时，协调者和参与者都继续提交事务，默认为成功，这也是根据概率统计上超时后默认成功的正确性最大
  缺点:
• 三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生网络分区（脑裂），系统仍然会发生数据不一致，好处就是至少不会阻塞和能够出现单点故障后继续达成一致。

• TCC协议
  三阶段提交协议与两阶段提交协议相比，具有如上的优点，但是一旦发生超时，系统仍然会发生不一致，只不过这种情况很少见罢了，好处就是至少不会阻塞和永远锁定资源。
  关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
• TCC事务机制相比于上面介绍的XA，解决了其几个缺点:
  1.解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器也变成多点，引入集群。
  2.同步阻塞:引入超时，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻辑形式，粒度变小。
  3.数据一致性，有了补偿机制之后，由业务活动管理器控制一致性
• TCC事务机制阶段
  Try阶段：尝试执行,完成所有业务检查（一致性）,预留必须业务资源（准隔离性）
  Confirm阶段：确认执行真正执行业务，不作任何业务检查，只使用Try阶段预留的业务资源，Confirm操作满足幂等性。要求具备幂等设计，Confirm失败后需要进行重试。
  Cancel阶段：取消执行，释放Try阶段预留的业务资源
  Cancel操作满足幂等性Cancel阶段的异常和Confirm阶段异常处理方案基本上一致。
  

其他分布式事务解决方案

• 如何保证分布式数据最终一致性?
• 本地消息表
  此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景，通过对账系统对事后问题的处理。
  
  本地消息队列是BASE理论，是最终一致模型，适用于对一致性要求不高的。实现这个模型时需要注意重试的幂等。
• MQ事务，也可以参考rabbitMQ
  
  基本流程如下:
  第一阶段Prepared消息，会拿到消息的地址。
  第二阶段执行本地事务。
  第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。消息接受者就能使用这个消息。
  如果确认消息失败，在RocketMq Broker中提供了定时扫描没有更新状态的消息，如果有消息没有得到确认，会向消息发送者发送消息，来判断是否提交，在rocketmq中是以listener的形式给发送者，用来处理
  
  如果消费超时，则需要一直重试，消息接收端需要保证幂等。如果消息消费失败，这个就需要人工进行处理，因为这个概率较低，如果为了这种小概率时间而设计这个复杂的流程反而得不偿失
• Saga事务
  saga模式没有隔离性的影响还是较大，可以参照华为的解决方案:从业务层面入手加入一 Session 以及锁的机制来保证能够串行化操作资源。也可以在业务层面通过预先冻结资金的方式隔离这部分资源， 最后在业务操作的过程中可以通过及时读取当前状态的方式获取到最新的更新。
  具体实例:可以参考华为的servicecomb

如何保证幂等性：

• 使用数据库表的唯一键进行滤重，拒绝重复的请求
• 使用分布式表对请求进行滤重
• 使用状态流转的方向性来滤重，通常使用行级锁来实现
• 利用上面说的MQ事务

去哪儿网分布式事务方案

• 优先使用异步消息。
  幂等有两种方式，一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成，如果当前状态是支付完成，则再收到一个支付成功的消息则说明消息重复了，直接作为消息成功处理。
  另外一种方式如果业务逻辑无法保证幂等，则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库，发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出，而是向消息库插入一条消息记录，然后在事务提交的时候再异步将消息发出，发送消息如果成功则将消息库里的消息删除，如果遇到消息队列服务异常或网络问题，消息没有成功发出那么消息就留在这里了，会有另外一个服务不断地将这些消息扫出重新发送。

• 有的业务不适合异步消息的方式，事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似，每个参与方的本地业务库的同实例上面放一个事务记录库。
  实际上可以依靠运维的手段来简化开发的侵入，我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库，通过框架层（消息的客户端或事务 RPC 框架）透明的在背后操作这个库，业务开发人员只需要关心自己的业务逻辑，不需要直接访问这个库。
  总结起来，其实两种方式的根本原理是类似的，也就是将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性

• 根据业务的特点，操作本身就是幂等的，例如：删除一个资源、增加一个资源、获得一个资源等

• 比如这个例子：如果产生了一笔交易，需要在交易表增加记录，同时还要修改用户表的金额。这两个表属于不同的远程服务，所以就涉及到分布式事务一致性的问题。
  
  经典的解决方法，将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题，达到多次重试的幂等性，增加一个更新记录表 updates_applied 来记录已经处理过的消息。
  在第一阶段，通过本地的数据库的事务保障，增加了 transaction 表及消息队列 。
  在第二阶段，分别读出消息队列（但不删除），通过判断更新记录表 updates_applied 来检测相关记录是否被执行，未被执行的记录会修改 user 表，然后增加一条操作记录到 updates_applied，事务执行成功之后再删除队列。
  通过以上方法，达到了分布式系统的最终一致性。

阿里云服务的话可以使用GTS（终极解决方案）

其他厂商案例：

• 蘑菇街交易创建过程中的分布式一致性方案
  功能进行垂直拆分
  
  面临的问题
  每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢？比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理？再比如锁券成功了，但是扣减库存失败了，该如何处理？
  拆分大的流程为多个小的本地事务的前提下，
  a、对于非实时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联事务异步化执行的方案。
  消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。
  但是事务消息框架本身会给业务代码带来侵入性和复杂性，所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦，通过订阅方消费 MQ 消息时的 ACK 机制，保证消息一定消费成功，达到最终一致性。由于消息可能会被重发，消息订阅方业务逻辑处理要做好幂等保证。
  b、需要实时同步做、有强一致性要求的业务场景
  在交易创建过程中，锁券和扣减库存是这样的两个典型场景。
  在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁券和扣减库存时，针对调用异常（失败或者超时），发出废单消息到MQ。如果消息发送失败，本地会做时间阶梯式的异步重试；优惠券系统和库存系统收到消息后，会进行判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。
• 支付宝及蚂蚁金融云的分布式服务 DTS 方案其实就是上面说的TCC
  分布式事务服务简介
  分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架，用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分，前者是一个嵌入客户端应用的 JAR 包，主要负责事务数据的写入和处理；后者是一个独立的系统，主要负责异常事务的恢复。
  核心特性
  传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下，ACID 模型能有效保障数据的完整性，但是在大规模分布式环境下，一个业务往往会跨越多个数据库，如何保证这多个数据库之间的数据一致性，需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题，但是 2PC 是反可伸缩模式，也就是说，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模达到千万级以上时，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。基于此，我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案，这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求，其最大的特点是保证数据最终一致 (Eventually consistent)。
  简单的说，DTS 框架有如下特性：
  最终一致：事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。
  协议简单：DTS 定义了类似 2PC 的标准两阶段接口，业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。
  与 RPC 服务协议无关：在 SOA 架构下，一个或多个 DB 操作往往被包装成一个一个的 Service，Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上，与底层协议无关。
  与底层事务实现无关： DTS 是一个抽象的基于 Service 层的概念，与底层事务实现无关，也就是说在 DTS 的范围内，无论是关系型数据库 MySQL，Oracle，还是 KV 存储 MemCache，或者列存数据库 HBase，只要将对其的操作包装成 DTS 的参与者，就可以接入到 DTS 事务范围内。
  
  实现
  一个完整的业务活动由一个主业务服务与若干从业务服务组成。
  主业务服务负责发起并完成整个业务活动。
  从业务服务提供 TCC 型业务操作。
  业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的 confirm 操作，在业务活动取消时调用所有两阶段事务的 cancel 操作。”
  与 2PC 协议比较
  没有单独的 Prepare 阶段，降低协议成本
  系统故障容忍度高，恢复简单
• 农信网数据一致性方案
  电商业务
  公司的支付部门，通过接入其它第三方支付系统来提供支付服务给业务部门，支付服务是一个基于 Dubbo 的 RPC 服务。
  对于业务部门来说，电商部门的订单支付，需要调用
  支付平台的支付接口来处理订单；
  同时需要调用积分中心的接口，按照业务规则，给用户增加积分。
  从业务规则上需要同时保证业务数据的实时性和一致性，也就是支付成功必须加积分。
  我们采用的方式是同步调用，首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付，由积分平台提供增加与回撤接口。
  具体的流程是先调用积分平台增加用户积分，再调用支付平台进行支付处理，如果处理失败，catch 方法调用积分平台的回撤方法，将本次处理的积分订单回撤。
  用户信息变更
  公司的用户信息，统一由用户中心维护，而用户信息的变更需要同步给各业务子系统，业务子系统再根据变更内容，处理各自业务。用户中心作为 MQ 的 producer，添加通知给 MQ。APP Server 订阅该消息，同步本地数据信息，再处理相关业务比如 APP 退出下线等。
  我们采用异步消息通知机制，目前主要使用 ActiveMQ，基于 Virtual Topic 的订阅方式，保证单个业务集群订阅的单次消费。
  

看完复习：

1. ACID和CAP的 CA是一样的吗？
2. 分布式事务常用的解决方案的优缺点是什么？适用于什么场景？
3. 分布式事务出现的原因？用来解决什么痛点？