事务
什么是事务？引用wiki的描述，解释下什么是事务。
是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成
数据库系统具有事务特性，这是其有别与文件系统重要特性。传统的文件系统，如果正在写文件，操作系统突然崩溃，此时文件可能被破坏。数据库系统引入事务特性，可以保证数据库从一种状态转换为另一种状态。在提交工作时，可以确保要么所有修改都被保存，要么所有都不保存。
事务具有四个基本特性，俗称 ACID。
原子性（Atomicity）
事务会被当做一个不可分割的整体，要么所有语句都成功，要么都失败。
一致性（Consistenc）
数据库的状态从一种状态转变为另外一种状态，事务开始之前和事务结束之后，数据库完整性约束不变。什么叫数据库完整性约束不变？举个例子，若一个表姓名字段为唯一约束，若在事务提交或回滚后，姓名字段变成非唯一了，这就破坏数据库的完整性约束。
隔离性（Isolation）
一个事务的执行不能被其他事务干扰，多个并发事务执行，互不影响。
持久性 （Durability）
指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
因此早期我们的系统在只存在一个数据源情况下，这个时候可以依靠数据库系统事务来保证业务的正确性。但是随着业务的不断扩展，我们业务的一个单表可能就存在千万数据，在使用一个数据库实例时，就可能会存在性相关能问题。这个时候我们就会考虑分库分表。但是这样就有可能导致，单个应用连接多个数据源的情况，如下图示例。
上图一次购买过程，商家余额表与用户余额表处于两个单独的数据库实例中，这样单独的事务能保证扣减商家余额或用户余额要么扣减成功，要么扣减失败。但是我们却无法保证两个事务同时成功或同时失败。
还有一种情况，随着系统越来越庞大，我们会选择将系统应用拆分多个微服务，让单个应用只操作一个数据源。这个时候我们就会碰到，一次业务调用，将会调用多个应用，每个应用单独操作数据源的情况，如下图。
这种情况下我们更加不能保证所有调用都成功。
由上面的例子下我们可以看出，随着业务发展，传统的单机事务已经无法满足我们的业务需求，这个时候我们就需要分布式事务来保证。
分布式事务
摘抄一段 wiki 上解释。
A distributed transaction is a database transaction in which two or more network hosts are involved.
我们先来讲下实现分布式事务一些理论基础。
分布式事务技术理论
CAP定理
CAP 定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出 WEB 服务无法同时满足一下3个属性
- 一致性（Consistency）： 客户端知道一系列的操作都会同时发生（生效）。
- 可用性（Availability）： 每个操作都必须以可预期的响应结束。
- 分区容错性（Partition tolerance）：即使出现单个组件无法可用，操作依然可以完成。
在分布式系统中，分区容错性是基本的要求，而可用性往往比一致性更重要。因此在 CAP 定理进行进一步扩充，得到一个 BASE 理论。
BASE理论
- 基本可用（Basically Available）：整个系统在某些不可抗力的情况下，仍然能够保证“可用性”，即一定时间内仍然能够返回一个明确的结果。
- 柔性状态（Soft state）：同一数据的不同副本的状态，可以不需要实时一致。
- 最终一致性（Eventually consistent）：同一数据的不同副本的状态，可以不需要实时一致，但一定要保证经过一定时间后仍然是一致的。
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
分布式事务解决方案
方案1：2PC
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
两个阶段:
- 准备阶段（投票阶段），写 redo 和 undo 日志，但不提交。
- 提交阶段（执行阶段），根据协调者那得到的消息，提交或者回滚。
如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
不管最后结果如何，第二阶段都会结束当前事务，并释放所有资源。
提交过程:
所有参与者节点在第一阶段都响应"同意"
- 协调者节点向所有参与者节点发出“正式提交（commit）”的请求。
- 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送”完成”消息。
- 协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
有参与者节点在第一阶段响应"中止"或超时
- 协调者节点向所有参与者节点发出”回滚操作（rollback）”的请求。
- 参与者节点利用之前写入的 undo 信息执行回滚，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送”回滚完成”消息。
- 协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。
2PC的缺点
- 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。
- 单点故障。由于协调者的重要性，一旦协调者发生故障，参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）。
- 数据不一致。在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这会导致只有一部分参与者接受到了 commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
- 协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
方案2：TCC
TCC 即为 Try Confirm Cancel，它属于补偿型分布式事务。顾名思义，TCC 实现分布式事务一共有三个步骤
- Try：尝试待执行的业务
- 这个过程并未执行业务，只是完成所有业务的一致性检查，并预留好执行所需的全部资源
- Confirm：执行业务
- 这个过程真正开始执行业务，由于Try阶段已经完成了一致性检查，因此本过程直接执行，而不做任何检查。并且在执行的过程中，会使用到Try阶段预留的业务资源。
- Cancel：取消执行的业务
- 若业务执行失败，则进入Cancel阶段，它会释放所有占用的业务资源，并回滚Confirm阶段执行的操作。
下面以一个转账的例子来解释下TCC实现分布式事务的过程。
假设用户A用他的账户余额给用户B发一个100元的红包，并且余额系统和红包系统是两个独立的系统。
- Try
- 创建一条转账流水，并将流水的状态设为交易中
- 将用户A的账户中扣除100元（预留业务资源）
- Try成功之后，便进入Confirm阶段
- Try过程发生任何异常，均进入Cancel阶段
- Confirm
- 向B用户的红包账户中增加100元
- 将流水的状态设为交易已完成
- Confirm过程发生任何异常，均进入Cancel阶段
- Confirm过程执行成功，则该事务结束
- Cancel
- 将用户A的账户增加100元
- 将流水的状态设为交易失败
在传统事务机制中，业务逻辑的执行和事务的处理，是在不同的阶段由不同的部件来完成的：业务逻辑部分访问资源实现数据存储，其处理是由业务系统负责；事务处理部分通过协调资源管理器以实现事务管理，其处理由事务管理器来负责。二者没有太多交互的地方，所以，传统事务管理器的事务处理逻辑，仅需要着眼于事务完成（commit/rollback）阶段，而不必关注业务执行阶段。
方案3：消息队列中间件
这种实现分布式事务的方式需要通过消息中间件来实现。假设有A和B两个系统，分别可以处理任务A和任务B。此时系统A中存在一个业务流程，需要将任务A和任务B在同一个事务中处理。下面来介绍基于消息中间件来实现这种分布式事务。
- 在系统A处理任务A前，首先向消息中间件发送一条消息
- 消息中间件收到后将该条消息持久化，但并不投递。此时下游系统B仍然不知道该条消息的存在。
- 消息中间件持久化成功后，便向系统A返回一个确认应答；
- 系统A收到确认应答后，则可以开始处理任务A；
- 任务A处理完成后，向消息中间件发送Commit请求。该请求发送完成后，对系统A而言，该事务的处理过程就结束了，此时它可以处理别的任务了。 但commit消息可能会在传输途中丢失，从而消息中间件并不会向系统B投递这条消息，从而系统就会出现不一致性。这个问题由消息中间件的事务回查机制完成，下文会介绍。
- 消息中间件收到Commit指令后，便向系统B投递该消息，从而触发任务B的执行；
- 当任务B执行完成后，系统B向消息中间件返回一个确认应答，告诉消息中间件该消息已经成功消费，此时，这个分布式事务完成。
上述过程可以得出如下几个结论：
- 消息中间件扮演者分布式事务协调者的角色。
- 系统A完成任务A后，到任务B执行完成之间，会存在一定的时间差。在这个时间差内，整个系统处于数据不一致的状态，但这短暂的不一致性是可以接受的，因为经过短暂的时间后，系统又可以保持数据一致性，满足BASE理论。
上述过程中，如果任务A处理失败，那么需要进入回滚流程，如下图所示：
- 若系统A在处理任务A时失败，那么就会向消息中间件发送Rollback请求。和发送Commit请求一样，系统A发完之后便可以认为回滚已经完成，它便可以去做其他的事情。
- 消息中间件收到回滚请求后，直接将该消息丢弃，而不投递给系统B，从而不会触发系统B的任务B。
此时系统又处于一致性状态，因为任务A和任务B都没有执行。
上面所介绍的Commit和Rollback都属于理想情况，但在实际系统中，Commit和Rollback指令都有可能在传输途中丢失。那么当出现这种情况的时候，消息中间件是如何保证数据一致性呢？——答案就是超时询问机制。
系统A除了实现正常的业务流程外，还需提供一个事务询问的接口，供消息中间件调用。当消息中间件收到一条事务型消息后便开始计时，如果到了超时时间也没收到系统A发来的Commit或Rollback指令的话，就会主动调用系统A提供的事务询问接口询问该系统目前的状态。该接口会返回三种结果：
- 提交 若获得的状态是“提交”，则将该消息投递给系统B。
- 回滚 若获得的状态是“回滚”，则直接将条消息丢弃。
- 处理中 若获得的状态是“处理中”，则继续等待。
消息中间件的超时询问机制能够防止上游系统因在传输过程中丢失Commit/Rollback指令而导致的系统不一致情况，而且能降低上游系统的阻塞时间，上游系统只要发出Commit/Rollback指令后便可以处理其他任务，无需等待确认应答。而Commit/Rollback指令丢失的情况通过超时询问机制来弥补，这样大大降低上游系统的阻塞时间，提升系统的并发度。
下面来说一说消息投递过程的可靠性保证。 当上游系统执行完任务并向消息中间件提交了Commit指令后，便可以处理其他任务了，此时它可以认为事务已经完成，接下来消息中间件一定会保证消息被下游系统成功消费掉！那么这是怎么做到的呢？这由消息中间件的投递流程来保证。
消息中间件向下游系统投递完消息后便进入阻塞等待状态，下游系统便立即进行任务的处理，任务处理完成后便向消息中间件返回应答。消息中间件收到确认应答后便认为该事务处理完毕！
如果消息在投递过程中丢失，或消息的确认应答在返回途中丢失，那么消息中间件在等待确认应答超时之后就会重新投递，直到下游消费者返回消费成功响应为止。当然，一般消息中间件可以设置消息重试的次数和时间间隔，比如：当第一次投递失败后，每隔五分钟重试一次，一共重试3次。如果重试3次之后仍然投递失败，那么这条消息就需要人工干预。
有的同学可能要问：消息投递失败后为什么不回滚消息，而是不断尝试重新投递？
这就涉及到整套分布式事务系统的实现成本问题。 我们知道，当系统A将向消息中间件发送Commit指令后，它便去做别的事情了。如果此时消息投递失败，需要回滚的话，就需要让系统A事先提供回滚接口，这无疑增加了额外的开发成本，业务系统的复杂度也将提高。对于一个业务系统的设计目标是，在保证性能的前提下，最大限度地降低系统复杂度，从而能够降低系统的运维成本。
不知大家是否发现，上游系统A向消息中间件提交Commit/Rollback消息采用的是异步方式，也就是当上游系统提交完消息后便可以去做别的事情，接下来提交、回滚就完全交给消息中间件来完成，并且完全信任消息中间件，认为它一定能正确地完成事务的提交或回滚。然而，消息中间件向下游系统投递消息的过程是同步的。也就是消息中间件将消息投递给下游系统后，它会阻塞等待，等下游系统成功处理完任务返回确认应答后才取消阻塞等待。为什么这两者在设计上是不一致的呢？
首先，上游系统和消息中间件之间采用异步通信是为了提高系统并发度。业务系统直接和用户打交道，用户体验尤为重要，因此这种异步通信方式能够极大程度地降低用户等待时间。此外，异步通信相对于同步通信而言，没有了长时间的阻塞等待，因此系统的并发性也大大增加。但异步通信可能会引起Commit/Rollback指令丢失的问题，这就由消息中间件的超时询问机制来弥补。
那么，消息中间件和下游系统之间为什么要采用同步通信呢？
异步能提升系统性能，但随之会增加系统复杂度；而同步虽然降低系统并发度，但实现成本较低。因此，在对并发度要求不是很高的情况下，或者服务器资源较为充裕的情况下，我们可以选择同步来降低系统的复杂度。 我们知道，消息中间件是一个独立于业务系统的第三方中间件，它不和任何业务系统产生直接的耦合，它也不和用户产生直接的关联，它一般部署在独立的服务器集群上，具有良好的可扩展性，所以不必太过于担心它的性能，如果处理速度无法满足我们的要求，可以增加机器来解决。而且，即使消息中间件处理速度有一定的延迟那也是可以接受的，因为前面所介绍的BASE理论就告诉我们了，我们追求的是最终一致性，而非实时一致性，因此消息中间件产生的时延导致事务短暂的不一致是可以接受的。
