事务简介
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。在关系数据库中，一个事务由一组SQL语句组成。事务应该具有4个属性：原子性、一致性、隔离性、持久性。
这四个属性通常称为ACID特性。
原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观察到的。
隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。
持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。
任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务，及时不能都很好的满足，也要考虑支持到什么程度。
事务分为本地事务和分布式事务
本地事务
@Transational注解
大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务称之为本地事务(Local Transaction)。本地事务的ACID特性是数据库直接提供支持。本地事务应用架构如下所示：
分布式事务
当下互联网发展如火如荼，绝大部分公司都进行了数据库拆分和服务化(SOA)。在这种情况下，完成某一个业务功能可能需要横跨多个服务，操作多个数据库。这就涉及到到了分布式事务，用需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据的操作，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。
典型的分布式事务场景：
跨库事务：跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。
分库分表：通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。例如对于一个简单的查询操作，数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。
服务化：例如某个应用同时操作了多个库，这样的应用业务逻辑必然非常复杂，对于开发人员是极大的挑战，应该拆分成不同的独立服务，以简化业务逻辑。拆分后，独立服务之间通过RPC框架来进行远程调用，实现彼此的通信。
Service A完成某个功能需要直接操作数据库，同时需要调用Service B和Service C，而Service B又同时操作了2个数据库，Service C也操作了一个库。需要保证这些跨服务的对多个数据库的操作要不都成功，要不都失败，实际上这可能是最典型的分布式事务场景。
小结：上述讨论的分布式事务场景中，无一例外的都直接或者间接的操作了多个数据库。如何保证事务的ACID特性，对于分布式事务实现方案而言，是非常大的挑战。同时，分布式事务实现方案还必须要考虑性能的问题，如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。
分析与思考：
在我们之前的开发中（如：使用Spring申明式事务）， 单体应用需要下单，图中操作只是调用本地应用的两个方法，这时候只需要使用@Transactional申明式事务，这个时候就能保证事务数据的一致性。
但是在我们调用updateOrder()的时候是order的数据库，而调用updateStock()的时候调用的是stock的数据库，这时我们的事务就不能生效了，不能保证事务的一致性和原子性。我们知道事务的底层的底层还是要基于Connection，所有的事务提交方法，事务回滚方法，事务自动提交都是依赖于Jdbc的核心对象-Connection对象。connection代表的就是一次数据库的连接，不同的数据库就有不同的数据库的连接，就会有不同的connection的事务。这种情况下就是我们的分布式事务。如下图：
如果这时候把下单服务，拆成订单服务和库存服务，这时候即使使用的是同一个事务也不能保证他们的数据一致性，因为不同的服务使用的是不同的进程，使用本地事务是不能做到统一提交统一回滚的。
这时候就需要分布式事务的解决方案（例如Seata，消息队列，saga，XA等），才能解决分布式事务的场景。
分布式事务理论基础
常见分布式事务解决方案
1、seata 阿里分布式事务框架
2、消息队列
3、saga
4、XA
他们有一个共同点，都是“两阶段(2PC)”。“两阶段”是指完成整个分布式事务，划分成两个步骤完成。
这四种常见的分布式事务解决方案，分别对应着 分布式事务的四种模式：AT、TCC、Saga、XA；四种分布式事务模式，都有各自的理论基础，分别在不同的时间被提出；每种模式都有它的适用场景，同样每个模式也都诞生有各自的代表产品；而这些代表产品，可能就是我们常见的(全局事务、基于可靠消息、最大努力通知、TCC)。
解决分布式事务，也有相应的规范和协议。分布式事务相关的协议有2PC、3PC。由于 三阶段提交协议3PC 非常难实现，目前市面主流的分布式事务解决方案都是2PC协议。目前绝大多数分布式解决方案都是以两阶段提交协议2PC为基础的。TCC（Try-Confirm-Cancel） 实际上是服务化的两阶段提交协议。
2PC两阶段提交协议：
PC(两阶段提交，Two-Phase Commit)顾名思义，分为两个阶段：Prepare 和 Commit
Prepare：提交事务请求
基本流程如下：
1，询问 协调者向所有参与者发送事务请求，询问是否可执行事务操作，然后等待各个参与者的响应。
2，执行 各个参与者接收到协调者事务请求后，执行事务操作(例如更新一个关系型数据库表中的记录)，并将Undo 和 Redo 信息记录事务日志中。参与者处于阻塞状态不能做其他的事情。
3，响应 如果参与者成功执行了事务并写入 Undo 和 Redo 信息，则向协调者返回 YES 响应，否则返回 NO响应。当然，参与者也可能宕机，从而不会返回响应。
Commit：执行事务提交
正常提交事务
流程如下图：
执行事务提交分为两种情况，正常提交和回退。
1，commit 请求 协调者向所有参与者发送 Commit 请求。
2，事务提交 参与者收到 Commit 请求后，执行事务提交，提交完成后释放事务执行期占用的所有资源。
3，反馈结果 参与者执行事务提交后向协调者发送 Ack 响应。
4，完成事务 接收到所有参与者的 Ack 响应后，完成事务提交。
中断事务
在执行 Prepare 步骤过程中，如果某些参与者执行事务失败、宕机或与协调者之间的网络中断，那么协调者就无法
收到所有参与者的 YES 响应，或者某个参与者返回了 No 响应，此时，协调者就会进入回退流程，对事务进行回
退。流程如下图红色部分(将 Commit 请求替换为红色的 Rollback 请求)：
1，rollback 请求 协调者向所有参与者发送 Rollback 请求。
2，事务回滚 参与者收到 Rollback 后，使用 Prepare 阶段的 Undo 日志执行事务回滚，完成后释放事务执行期占用的所有资源。
3，反馈结果 参与者执行事务回滚后向协调者发送 Ack 响应。
4，中断事务 接收到所有参与者的 Ack 响应后，完成事务中断。
2PC 的问题
- 同步阻塞 参与者在等待协调者的指令时，其实是在等待其他参与者的响应，在此过程中，参与者是无法进行其他操作的，也就是阻塞了其运行。 倘若参与者与协调者之间网络异常导致参与者一直收不到协调者信息，那么会导致参与者一直阻塞下去。
- 单点 在 2PC 中，**一切请求都来自协调者，所以协调者的地位是至关重要的，如果协调者宕机，那么就会使参与者一直阻塞并一直占用事务资源。**如果协调者也是分布式，使用选主方式提供服务，那么在一个协调者挂掉后，可以选取另一个协调者继续后续的服务，可以解决单点问题。但是，新协调者无法知道上一个事务的全部状态信息(例如已等待 Prepare 响应的时长等)，所以也无法顺利处理上一个事务。
- 数据不一致 Commit 事务过程中 Commit 请求/Rollback 请求可能因为协调者宕机或协调者与参与者网络问题丢失，那么就导致了部分参与者没有收到 Commit/Rollback 请求，而其他参与者则正常收到执行了Commit/Rollback 操作，没有收到请求的参与者则继续阻塞。这时，参与者之间的数据就不再一致了。当参与者执行 Commit/Rollback 后会向协调者发送 Ack，然而协调者不论是否收到所有的参与者的 Ack，该事务也不会再有其他补救措施了，协调者能做的也就是等待超时后像事务发起者返回一个“我不确定该事务是否成功”。（不能保证100%事务成功率，只能尽量保证事务的成功率）。
- 环境可靠性依赖 协调者 Prepare 请求发出后，等待响应，然而如果有参与者宕机或与协调者之间的网络中断，都会导致协调者无法收到所有参与者的响应，那么在 2PC 中，协调者会等待一定时间，然后超时后，会触发事务中断，在这个过程中，协调者和所有其他参与者都是出于阻塞的。这种机制对网络问题常见的现实环境来说太苛刻了。
分布式解决方式–AT模式
AT 模式是一种无侵入的分布式事务解决方案。阿里seata框架，实现了该模式。
在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
AT 模式如何做到对业务的无侵入 ：
一阶段：
在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
二阶段提交：
二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。
总结；利用业务的SQL,全自动的帮我们进行事务的提交， 提交第一阶段完成了同时第一阶段进行了行锁。如果第二阶段是提交的话就会把行锁删除其他的线程就可以查到这条数据了。如果是第二阶段是回滚的话把before image逆向的生成update SQL语句，然后还原回去。
分布式解决方案–TCC模式
1，侵入性比较强， 并且得自己实现相关事务控制逻辑
2，在整个过程基本没有锁，性能更强
TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
TCC 三个方法描述：
Try：资源的检测和预留；
Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；
Cancel：预留资源释放；
什么是Seata?
官方：A distributed transaction solution with high performance and ease of use for microservices architecture.(一种高性能、易用的微服务架构分布式事务解决方案)
**Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。**AT是阿里首推的模式。
官方文档：http://seata.io/zh-cn/docs/overview/what-is-seata.html
源码：https://github.com/seata/seata
Seata的三大角色
TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。
在 Seata 中，一个分布式事务的生命周期如下：
有关其他详细文档阅查看官网：https://seata.io/zh-cn/docs/overview/what-is-seata.html
Seata Client快速开始
环境部署点击
