分布式事务优化

Solution.md

@@ -5921,119 +5921,104 @@ Saga事务模型又叫做长时间运行的事务。其核心思想是**「将
 
 ## Seate
 
-**XA和Seata区别**
-
-![XA和Seata的区别](images/Solution/xa-seata.png)
-
-![XA过程](images/Solution/XA过程.png)
-
-![seata过程](images/Solution/seata过程.png)
-
-Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。
+Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。目前已支持Dubbo、Spring Cloud、Sofa-RPC、Motan和grpc等RPC框架。
 
 ![seata流程](images/Solution/seata流程.png)
 
-在 Seata 中，分布式事务的执行流程：
-
-- TM 开启分布式事务（TM 向 TC 注册全局事务记录）
-- 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）
-- TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）
-- TC 汇总事务信息，决定分布式事务是提交还是回滚
-- TC 通知所有 RM 提交/回滚 资源，事务二阶段结束
+Seata主要分为以下三大模块：
 
-![seata](images/Solution/seata.png)
+- **TC (Transaction Coordinator) - 事务协调者**
 
-- Transaction Coordinator(TC)
+  维护全局和分支事务的状态，驱动全局事务提交或回滚。
 
-事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
+- **TM (Transaction Manager) - 事务管理器**
 
-- Transaction Manager(TM)
+  定义全局事务的范围：开始全局事务、提交或回滚全局事务。
 
-控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
+- **RM (Resource Manager) - 资源管理器**
 
-- Resource Manager(RM)
+  管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
 
-控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
-
-
-
-Seata 会有 4 种分布式事务解决方案，分别是：AT 模式、TCC 模式、Saga 模式和 XA 模式。
-
-![seata发展历程](images/Solution/seata发展历程.png)
+> 注意：其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。
 
 
 
 ### AT模式
 
-2019年1月，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。
+AT模式提供了无侵入自动补偿的事务模式，目前已支持MySQL、Oracle、PostgreSQL、TiDB和MariaDB的AT模式，H2、DB2、SQLServer等。
 
 ![AT 模式](images/Solution/AT模式.png)
 
-**AT模式如何做到对业务的无侵入 ：**
+**AT模式的前提：**
 
-- **一阶段**
+- **基于支持本地 ACID事务的关系型数据库**
+- **Java应用，通过JDBC访问数据库**
 
-在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
 
-![AT模式一阶段](images/Solution/AT模式一阶段.png)
 
-- **二阶段提交**
-
-二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。
+**整体机制**
 
-![AT模式二阶段提交](images/Solution/AT模式二阶段提交.png)
+- 第一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源
+- 第二阶段
+  - 提交异步化，非常快速地完成
+  - 回滚通过一阶段的回滚日志进行反向补偿
 
-- **二阶段回滚**
 
-二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
 
-![AT模式二阶段回滚](images/Solution/AT模式二阶段回滚.png)
+### TCC模式
 
-AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。
+一个分布式的全局事务，整体是 **两阶段提交** 的模型。全局事务是由若干分支事务组成的，分支事务要满足 **两阶段提交** 的模型要求，即需要每个分支事务都具备自己的：
 
+- 一阶段 prepare 行为
+- 二阶段 commit 或 rollback 行为
 
+![Seate-TCC](images/Solution/Seate-TCC.png)
 
-### TCC模式
+根据两阶段行为模式的不同，我们将分支事务划分为：
 
-2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。
+- **Automatic (Branch) Transaction Mode**
+- **Manual (Branch) Transaction Mode**
 
-![TCC模式](images/Solution/TCC模式.png)
+AT 模式基于 **支持本地 ACID 事务** 的 **关系型数据库**：
 
-TCC 三个方法描述：
+- 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录
+- 二阶段 commit 行为：马上成功结束，**自动** 异步批量清理回滚日志
+- 二阶段 rollback 行为：通过回滚日志，**自动** 生成补偿操作，完成数据回滚
 
-- Try：资源的检测和预留
-- Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功
-- Cancel：预留资源释放
+TCC 模式，不依赖于底层数据资源的事务支持：
 
+- 一阶段 prepare 行为：调用 **自定义** 的 prepare 逻辑
+- 二阶段 commit 行为：调用 **自定义** 的 commit 逻辑
+- 二阶段 rollback 行为：调用 **自定义** 的 rollback 逻辑
 
+所谓 TCC 模式，是指支持把 **自定义** 的分支事务纳入到全局事务的管理中。
 
-**业务模型分 2 阶段设计：**
 
-用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。
 
-以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段 Try  成功的话 二阶段 Confirm 一定能成功。
+### Saga模式
 
-![kqcq](images/Solution/kqcq.png)
+Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
 
-如上图所示，Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的 转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。
+![Saga模式](images/Solution/Saga模式.png)
 
-二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。
+**适用场景：**
 
-如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。
+- **业务流程长、业务流程多**
+- **参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口**
 
-用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
 
 
+**优势：**
 
-### Saga模式
+- **一阶段提交本地事务，无锁，高性能**
+- **事件驱动架构，参与者可异步执行，高吞吐**
+- **补偿服务易于实现**
 
-Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
 
-分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
 
-![Saga模式](images/Solution/Saga模式.png)
+**缺点：**
 
-Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。
+- **不保证隔离性**