我要评论A(Atomic)原子性：构成事务的所有操作，要么都成功、要么都失败。
C(Consistency)一致性：事务执行前后，数据库的一致性约束没有被破坏。如：转账+-100要保证两边数据正确，如+100正确-100错误，导致了数据错误没达到一致性。
I(Isolation)隔离性：指并发的两个事务执行互不干扰，一个事务不能看到其他事务运行过程的中间状态。
D(Durability)持久性：事务完成后，该事物对数据的更改会被持久化到数据库，且不会被回滚。
分布式系统所产生的事务(多个服务间互相调用完成的事务)
2pc：两阶段提交（2指两个阶段、P指准备阶段、C指提交阶段）
整个事务过程由 事务管理器(决策整个分布式事务的提交和回滚) 和 参与者(负责自己本地事务的提交和回滚) 组成。
1.准备阶段：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。
2.提交阶段：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息，否则发送提交(Commit)消息。
参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。
基于数据库实现2PC协议所定义的方案(TM和RM之间通讯的接口规范叫XA)。在数据库层面实现的
AP应用程序、TM事务管理器、RM资源管理器(事务参与者，指数据库实例)
执行流程：
1.应用程序(AP)持有A库和B库两个数据源
2.应用程序(AP)通过TM通知A库RM新增数据，同时通知B库RM新增数据，RM此时未提交事务，此时A、B两库资源锁定。
3.TM收到执行回复，只要一方失败则分别向其他RM发起回滚事务，回滚完毕，资源释放。
3.TM收到执行回复，全部成功，此时向所有RM发起提交事务，提交完毕，资源释放。
交互方式：
1.TM向AP提供应用程序编程接口，AP通过TM提交及回滚事务。
2.TM交易中间件通过XA接口来通知RM数据库事务的开始、结束以及提交、回滚等。
问题：
1.需要本地数据库支持XA协议
2.资源锁需要等到两个阶段结束才能释放，性能较差。
开源的分布式事务框架，工作在应用层的中间件、性能较好且不长时间占用连接资源、对业务0侵入。
Transaction Coordinator(TC)：事务协调器，独立的中间件，需要独立部署运行，维护全局事务的运行状态，
接受TM指令发起全局事务的提交与回滚，负责与RM通信协调各个分支事务的提交与回滚。
Transaction Manager(TM)：事务管理器，需要嵌入应用程序工作(jar)，负责开启一个全局事务，并最终向TC发起全局提交或全局回滚的指令。
Resource Manager(RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器TC的指令，驱动分支事务提交或回滚操作。
执行流程：
1.服务A的TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。
2.服务A的RM向TC注册分支事务，该分支事务在服务A执行逻辑，并将其纳入XID对应全局事务的管辖。
3.服务A执行分支事务，向业务表做事务操作（新增/删除/修改）
4.逻辑执行到调用服务B时(XID在微服务调用链路的上下文中传播)。服务B的RM向TC注册分支事务，该分支事务执行逻辑，并将其纳入XID对应全局事务的管辖。
5.服务B执行分支事务，向业务表做事务操作（新增/删除/修改），执行完毕后返回服务A。
6.服务A分支事务执行完毕。
7.TM向TC发起针对XID的全局事务提交或回滚决议。
8.TC调度XID下管辖的全部分支事务完成提交或鬼滚请求。
Seata实现2PC与传统2PC的差别：
架构层次方面：传统的2PC方案的RM实际上是在数据库层，RM本质上就是数据库自身，通过XA协议实现。
Seata的RM以jar包形式作为中间层部署在应用程序。
两阶段提交方面：传统2PC无论第二阶段决议是commit或rollback，事务性资源锁都要保持到二阶段完成才释放。
Seata在一阶段就提交本地事务，省去二阶段持锁的时间，整体提高效率。
SpringCloud流程：
本文地址：https://blog.csdn.net/weixin_47746110/article/details/107209414
如对本文有疑问， 点击进行留言回复！！
Java/Python实现 LeetCode剑指Offer 14-I.剪绳子（动态规划）
Python - paramiko 模块远程执行ssh 命令 nohup 不生效的问题解决
网友评论