事务与分布式事务区别
事务
一个最小的不可再分的工作单元；通常一个事务对应一个完整的业务
事务四大特征(ACID)
- 原子性(A)：事务是最小单位，不可再分
- 一致性©：事务要求所有的DML语句操作的时候，必须保证同时成功或者同时失败
- 隔离性(I)：事务A和事务B之间具有隔离性
- 持久性(D)：是事务的保证，事务终结的标志(内存的数据持久到硬盘文件中)
事务隔离性-隔离级别
- 读未提交：read uncommitted
- 读已提交：read committed
- 可重复读：repeatable read
- 串行化：serializable
1、 读未提交 read uncommitted
- 脏读：读到未提交的数据
- 这种隔离级别最低，这种级别一般是在理论上存在，数据库隔离级别一般都高于该级别
2、读已提交 read committed
- 这种级别可以避免“脏数据”
- 这种隔离级别会导致“不可重复读取”
- Oracle默认隔离级别
3、可重复读 repeatable read
- MySQL默认级别
- 虽然可以达到可重复读取，但是会导致“幻像读”
方法：通过版本号控制读取数据(乐观锁实现)，保证在同一个事物中读取的都是同一条数据
4、串行化 serializable
- 事务A和事务B，事务A在操作数据库时，事务B只能排队等待
- 这种隔离级别很少使用，吞吐量太低，用户体验差
- 这种级别可以避免“幻像读”，每一次读取的都是数据库中真实存在数据，事务A与事务B串行，而不并发
事务开启标志：
任何一条DML语句(insert、update、delete)执行，标志事务的开启
事务结束标志(提交或者回滚)：
提交：成功的结束，将所有的DML语句操作历史记录和底层硬盘数据来一次同步 - 回滚：失败的结束，将所有的DML语句操作历史记录全部清空
事物与数据库底层数据
在事物进行过程中，未结束之前，DML语句是不会更改底层数据，只是将历史操作记录一下，在内存中完成记录。只有在事物结束的时候，而且是成功的结束的时候，才会修改底层硬盘文件中的数据
分布式事务
指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
例如：一个接口的调用内部包含三个服务器的接口，分布式事务可以保证三个服务器的操作全部成功或者全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
场景
跨JVM进程产生分布式事务
典型的场景就是微服务架构：微服务之间通过远程调用完成事务操作。比如：订单微服务和库存微服务，下单的同时订单微服务请求库存微服务减少库存。
跨数据库实例产生分布式事务
当单体应用需要访问多个数据库（实例）时就会产生分布式事务。
多服务访问同一个数据库实例
订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。
原则
CAP原则
C：一致性，执行前后的数据一致
A：可用性，保证服务一直可用（集群）如果其中一个服务器宕机了，不能影响整个集群对外提供服务
P：分区容错性，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供服务，满足一致性和可用性的服务
CAP的取舍策略：
BASE理论
BASE理论是对CAP理论的延伸，对AP的细化。
BA：基本可用：指分布式系统在出现故障时，为保证核心可用，允许损失部分可用性。
- 例如：电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。
S：软状态：是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性
例如：分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现
E：最终一致性：是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态
- 最终一致性是弱一致性的一种特殊情况。
核心思想：如果我们无法做到强一致性，那么每个应用都应该根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
BASE理论实现方案：
2PC：两阶段提交协议（Two-Phrase Commit）
两阶段提交协议的目标在于在分布式系统中保证数据的一致性：投票阶段和事务提交阶段
执行：
准备阶段：事务内包含的各个服务将自己的决策返回给管理者
同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）
**事务提交阶段：**管理者通过返回的决策来决定是否取消(少一条都不行)
缺点：
1.性能差：要等待所有的参与者处理完毕为止，性能较差（木桶原理）。
2.单点故障：如果管理者挂了，则服务仍旧处于锁定(阻塞)状态，管理者选举新的也无法解决
3.数据不一致：分布式系统，如果二阶段，commit后，其中一个服务突然挂了，则会导致数据不一致
3PC：三阶段提交协议
三阶段提交协议在协调者(管理者)和参与者中都引入超时机制，并且把两阶段提交协议的第一个阶段拆分成了两步：询问，然后再锁资源，最后真正提交。
准备：协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应
预提交：锁资源：发送预提交请求，参与者开始提交操作，如果成功执行事务操作，则返回ACK响应，失败返回NO或者返回超时，则中断事务
提交：管理者通过返回的响应，进行操作：提交/中断
2PC和3PC区别：
对于协调者(Coordinator)和参与者(Cohort)都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到cohort的消息则默认失败）。 在2PC的准备阶段和提交阶段之间，插入预提交阶段，使3PC拥有CanCommit、PreCommit、DoCommit三个阶段。 PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
优点：3PC相比2PC，会先询问事务参与者是否有条件接事务，不会直接锁资源，降低了阻塞范围，在等待超时后事务协调者或事务参与者会中断事务。避免了事务协调者单点故障问题，3PC的提交阶段中即使事务协调者出现问题时，事务参与者会继续提交事务。
缺点：引入一个阶段，多一次交互，性能比2PC更低，且绝大部分情况事务参与者都由能执行事务的条件，仍要先询问一次。而且数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
Seata 方案
是一个是开源的分布式事务框架。
与传统 2PC 的模型类似，Seata 定义了 3 个组件来协议分布式事务的处理过程：
Transaction Coordinator（TC）：事务协调器，它是独立的中间件，需要独立部署运行，它维护全局事务的运行状态，接收 TM 指令发起全局事务的提交与回滚，负责与 RM 通信协调各各分支事务的提交或回滚。
Transaction Manager（TM）： 事务管理器，TM 需要嵌入应用程序中工作，它负责开启一个全局事务，并最终向 TC 发起全局提交或全局回滚的指令。
Resource Manager（RM）：控制分支事务，负责分支注册、状态汇报，并接收事务协调器 TC 的指令，驱动分支（本地）事务的提交和回滚。
流程分析
- 用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。
- 用户服务的 RM 向 TC 注册分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局事务的管辖。
- 用户服务执行分支事务，向用户表插入一条记录。
- 逻辑执行到远程调用积分服务时（XID 在微服务调用链路的上下文中传播）。积分服务的 RM 向 TC 注册分支事务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。
- 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。
- 用户服务分支事务执行完毕。
- TM 向 TC 发起针对 XID 的全局提交或回滚决议。
- TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。
Seata方案与传统 2PC 方案对比，有以下优点：
架构层次方面：传统 2PC 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身，通过 XA 协议实现，而 Seata 的 RM 是以 jar 包的形式作为中间件层部署在应用程序这一侧的。
二阶段提交方面：传统 2PC无论提交阶段的决议是 commit 还是 rollback ，事务性资源的锁都要保持到 Phase2 完成才释放。而 Seata 的做法是在 Phase1 就将本地事务提交，这样就可以省去 Phase2 持锁的时间，整体提高效率。
由于 Seata 的 0 侵入性并且解决了传统 2PC 长期锁资源的问题，推荐采用 Seata 实现 2PC
各方案使用场景
2PC/3PC：依赖于数据库，能够很好的提供强一致性和强事务性，但相对来说延迟比较高，比较适合传统的单体应用，在同一个方法中存在跨库操作的情况，不适合高并发和高性能要求的场景。
TCC：适用于执行时间确定且较短，实时性要求高，对数据一致性要求高，比如互联网金融企业最核心的三个服务：交易、支付、账务。
本地消息表/MQ 事务：都适用于事务中参与方支持操作幂等，对一致性要求不高，业务上能容忍数据不一致到一个人工检查周期，事务涉及的参与方、参与环节较少，业务上有对账/校验系统兜底。
Saga 事务：由于 Saga 事务不能保证隔离性，需要在业务层控制并发，适合于业务场景事务并发操作同一资源较少的情况。 Saga 相比缺少预提交动作，导致补偿动作的实现比较麻烦，例如业务是发送短信，补偿动作则得再发送一次短信说明撤销，用户体验比较差。Saga 事务较适用于补偿动作容易处理的场景。
事务和分布式事务区别：
参考图：
参考资料：
https://blog.csdn.net/weixin_43318367/article/details/110346649
https://blog.csdn.net/ttzommed/article/details/112989510-分布式事务解决方案