事务相关知识点
2024-11-18 17:17:53 0 举报AI智能生成
Java事务相关知识点
作者其他创作
大纲/内容
Spring事务
编程式事务
声明式事务
分布式事务
分类
2PC
两阶段提交，将事务的提交过程分为资源准备和资源提交两个阶段
准备阶段
分支主题
提交阶段
事务提交
分支主题
事务回滚
分支主题
不足之处
性能问题
执行过程中，所有参与节点都是事务阻塞性的，当参与者占有公共资源时，其他第三方节点访问公共资源就不得不处于阻塞状态，为了数据的一致性而牺牲了可用性，对性能影响较大，不适合高并发高性能场景
可靠性问题
2PC非常依赖协调者，当协调者发生故障时，尤其是第二阶段，那么所有的参与者就会都处于锁定事务资源的状态中，而无法继续完成事务操作（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
数据一致性问题
在阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
二阶段无法解决的问题
协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了，那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。
3PC
三阶段提交协议，是二阶段提交协议的改进版本
CanCommit 准备阶段
PreCommit 阶段
执行事务
分支主题
中断事务
分支主题
doCommit阶段
提交事务
分支主题
中断事务
分支主题
优缺点
与2PC相比，3PC降低了阻塞范围，并且在等待超时后，协调者或参与者会中断事务，避免了协调者单点问题，阶段三中协调者出现问题时，参与者会继续提交事务。
数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者因为网络问题无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
分支主题
TCC
TCC（Try Confirm Cancel）是应用层的两阶段提交
第一阶段
Try
第二阶段
Confirm
Cancle
TCC如何保证最终一致性
资源预留与隔离，在Try阶段，TCC通过预留必要的业务资源并与其他操作隔离，确保了这些资源在后续阶段中能够被正确地使用或释放。这避免了资源冲突和数据不一致的问题。
幂等性保证，Confirm和Cancel阶段的操作都需要满足幂等性。这意味着无论这些阶段被执行多少次，只要参数相同，结果都应该相同。这确保了即使在网络故障、超时重试或并发请求的情况下，数据的一致性也不会被破坏。
事务回滚与补偿，如果Try阶段失败或事务被取消，TCC通过Cancel阶段来撤销预留的业务资源并释放它们。这实现了事务的回滚和补偿操作，确保了数据能够恢复到一致的状态。
全局事务管理，TCC方案通常包含一个全局事务管理器来管理和控制整个事务活动。它会记录并维护全局事务的事务状态和每个参与方的分支事务状态。当所有分支事务的Try阶段都执行成功时，全局事务管理器会自动调用每个分支事务的Confirm阶段操作来完成分布式事务；而当某些分支事务执行失败时，它会调用分支事务的Cancel操作来回滚分布式事务。
分支主题
Saga事务
实现方式
命令协调
流程
① 事务发起方的主业务逻辑请求 OSO 服务开启订单事务
② OSO 向库存服务请求扣减库存，库存服务回复处理结果。
③ OSO 向订单服务请求创建订单，订单服务回复创建结果。
④ OSO 向支付服务请求支付，支付服务回复处理结果。
⑤ 主业务逻辑接收并处理 OSO 事务处理结果回复。
优点
服务之间关系简单，避免服务间循环依赖，因为 Saga 协调器会调用 Saga 参与者，但参与者不会调用协调器。
程序开发简单，只需要执行命令/回复(其实回复消息也是一种事件消息)，降低参与者的复杂性。
易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试。
缺点
中央协调器处理逻辑容易变得庞大复杂，导致难以维护。
存在协调器单点故障风险。
分支主题
事件编排
流程
① 事务发起方的主业务逻辑发布开始订单事件。
② 库存服务监听开始订单事件，扣减库存，并发布库存已扣减事件。
③ 订单服务监听库存已扣减事件，创建订单，并发布订单已创建事件。
④ 支付服务监听订单已创建事件，进行支付，并发布订单已支付事件。
⑤ 主业务逻辑监听订单已支付事件并处理。
分支主题
优点
避免中央协调器单点故障风险。
当涉及的步骤较少服务开发简单，容易实现。
缺点
服务之间存在循环依赖的风险。
当涉及的步骤较多，服务间关系混乱，难以追踪调测。
恢复策略
向后恢复
分支主题
向前恢复
分支主题
本地消息表
流程
① 事务主动方在同一个本地事务中处理业务和写消息表操作
② 事务主动方通过消息中间件，通知事务被动方处理事务消息。消息中间件可以基于 Kafka、RocketMQ 消息队列，事务主动方主动写消息到消息队列，事务消费方消费并处理消息队列中的消息。
③ 事务被动方通过消息中间件，通知事务主动方事务已处理的消息。
④ 事务主动方接收中间件的消息，更新消息表的状态为已处理。
分支主题
优点
①从应用设计开发的角度实现了消息数据的可靠性，消息数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖。
②方案轻量，容易实现。
缺点
①与具体的业务场景绑定，耦合性强，不可公用
②消息数据与业务数据同库，占用业务系统资源
③业务系统在使用关系型数据库的情况下，消息服务性能会受到关系型数据库并发性能的局限
MQ事务消息
分支主题
最大努力通知
分支主题
Seata
核心组件
Transaction Coordinator（TC）
事务协调器，是分布式事务的控制者，负责维护全局和分支事务的状态，驱动全局事务的提交或回滚。
Transaction Manager（TM）
事务管理器，负责全局事务的提交和回滚等操作，与TC进行协作。
Resource Manager（RM）
资源管理器，负责管理和控制分支事务所涉及的资源（如数据库）的操作，与TC进行协作。
事务模式
AT模式
一阶段：TM向TC请求开启全局事务，TM调用每个RM分支，每个RM向TC注册自己分支事务，RM开始执行业务SQL，执行完成后，不提交事务并向TC报告事务的状态。
二阶段：业务执行完成后，TM向TC表明各个RM分支已经结束，此时TC检查分支事务的状态来决定是回滚还是进行提交事务。AT模式利用全局锁实现事务隔离，没有代码侵入，框架自动完成回滚和提交。但两阶段之间属于软状态，属于最终一致性，且框架的快照功能会影响性能。
TCC模式
Try阶段：资源检查和预留资源。例如，在转账事务中，A账户需要扣除100元，此时会将这100元写入一个中间表（如冻结金额表），并标记事务状态为Try。
Confirm阶段：如果Try阶段所有分支事务都成功，则执行Confirm中的代码，正常提交事务并删除中间表的记录。
Cancel阶段：如果Try阶段有分支事务失败，则执行Cancel中的方法，根据中间表的数据恢复原来的数据。
SAGA模式
XA模式
0 条评论
下一页
