阿里云服务器 放多个网站,桂林阳朔,tiktok跨境电商怎么做,公司网站背景图Seata AT 模式设计思路
一阶段#xff1a;业务数据和回滚日志记录在同一个本地事务中提交#xff0c;释放本地锁和连接资源。
核心在于对业务sql进行解决解析#xff0c;转换成undolog#xff0c;并同时入库存
二阶段#xff1a;
提交异步化#xff0c;非常快速地完成…Seata AT 模式设计思路
一阶段业务数据和回滚日志记录在同一个本地事务中提交释放本地锁和连接资源。
核心在于对业务sql进行解决解析转换成undolog并同时入库存
二阶段
提交异步化非常快速地完成则Tc通知RM异步删除undolog
回滚一阶段日志进行反向补偿tm向tc发送回滚请求RM收一协调器TC发来的回滚请求通过XID和Branch ID找到相应的回滚日志记录通过回滚记录生成反向的更新sql并执行以完成分支的回滚 两阶段提交协议(2PC)
阶段1TM(事务管理器)通知各个RM资源管理器)准备提交它们的事务分支
阶段2TM 根据阶段1各个RM prepare的结果决定是提交还是回滚事务。如果所有的RM都prepare成功那么TM通知所有的RM进行提交;如果有RM prepare失败的话则TM通知所有RM回滚自己的事务分支。
存在的问题
同步阻塞问题单点故障数据不一致 XA模式
执行阶段
可回滚业务SQL操作放在XA分支中进行由资源对XA协议来保证可回滚
持久化XA分支完成后执行XA prepare同样由资源对XA协议的来支持来保证持久化
完成阶段
分支提交执行XA分支的commit
分支回滚执行XA分支的rollback TCC模式
tcc基于分布式事务中的二阶段提交协议实现这化的全称为Try-Confirm-Cancel即资源预留(Try)、确认操作(Confirm)、取消操作(Cancel)他们的具体含义如下
Try对业务资源的检查并预留Confirm:对业务处理进行提交即commit操作只要Try成功那么该步骤一定成功Cancel对业务处理进行取消即回滚操作该步骤回对Try预留的资源进行释放。 TCC是一种侵入式的分布式事务解决方案对业务系统有着非常大的入侵性设计相对复杂
优点TCC完全不依赖数据库能够实现跨数据库、跨应用资源管理 Seata如何防止空回滚新增一个TCC事务控制表
如何处理幂等幂等问题指的是 TC 重复进行二阶段提交因此 Confirm/Cancel 接口需要支持幂等处理即不会产生资源重复提交或者重复释放。 如何处理悬挂在 TCC 事务控制表记录状态的字段 status 中增加一个状态 当执行二阶段 Cancel 方法时如果发现 TCC 事务控制表没有相关记录说明二阶段 Cancel 方法优 先一阶段 Try 方法执行因此插入一条 status4 状态的记录当一阶段 Try 方法后面执行时判断 status4 则说明有二阶段 Cancel 已执行并返回 false 以阻止一阶段 Try 方法执行成功
XA与TCC比较 XA是资源层面的分布式事务强一致性在两阶段提交的整个过程中一直会持有资源的锁。 TCC是业务层面的分布式事务最终一致性不会一直持有资源的锁 AT模式与TCC模式比较
区别在于
AT模式基于支持本地ACID事务的关系型库数据
一阶段prepare行为在本地事务中一并提交业务数据更新和相应回滚日志记录
二阶段commit行为马上成功结束自动异步批量清理回滚日志
二阶段rollback行为通过回滚日志自动生成补偿操作完成数据回滚 相应用的TCC模式不依赖于底层数据资源的事务支持
一阶段prepare行为调用自prepare逻辑
二阶段commit行为调用自定义的commit逻辑
二阶段rollback行为调用自定义的rollback逻辑。 简单点概括SEATA的TCC模式就是手工的AT的模式它允许你自定义两阶段的处理逻辑而不依赖AT模式的undo_log 可靠消息最终一致性
异步化在分布式系统设计中随处可见基于消息队列的最终一致性就是一种异步事务机制在业务中广泛应用。
本地消息表
将分布式事务拆分成本地事务进行处理通过消息日志的方式来异步执行。本地消息表是一种业务耦合的设计消息生产方需要额外建一个事务消息表并记录消息发送状态消息消费方需要处理这个消息并完成自己的业务逻辑另外会有一个异步机制来定期扫描未完成的消息确保最终一致性。
RocketMQ事务消息
RocketMQ事务消息是一种支持分布式事务的消息。它通过引入prepare、commit和rollback三个阶段来确保事务消息的一致性。
Prepare阶段消息发送方发送消息此时消息的状态为“待提交”commit阶段消息发送方向RocketMQ发送commit消息请求RocketMQ判断此时半消息是否被确认如果半消息已被确认则将消息标记为“可消费”并提交事务。如果半消息未被确认刚将消息标记为“不可消息”并终止事务。rollback阶段消息发送方向rocketMQ发送rollback消息请求RocketMQ将半消息标记为“不可消费”并回滚事务。
最大努力通知
最大努力通知型是最简单的一种柔性事务适用于一些最终一致性时间敏感度低的业务且被动方处理不影响主动方的处理结果。
最大努力通知实施方案一般符合以下特点
不可靠消息业务活动主动方在完成业务处理之后向业务活动的被动方发送消息直到通知N次后不再通知允许消息丢失不可靠消息定期校对业务活动的被动方根据定时策略向业务活动主动方查询主动方提供查询接口恢复丢失的业务消息
