网站做支付需要什么备案广州建设网站的公司
Seata AT 模式设计思路
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
核心在于对业务sql进行解决解析，转换成undolog，并同时入库存
二阶段：
提交异步化，非常快速地完成，则Tc通知RM异步删除undolog；
回滚一阶段日志进行反向补偿，tm向tc发送回滚请求，RM收一协调器TC发来的回滚请求，通过XID和Branch ID找到相应的回滚日志记录，通过回滚记录生成反向的更新sql并执行，以完成分支的回滚
两阶段提交协议(2PC)
阶段1：TM(事务管理器)通知各个RM（资源管理器)准备提交它们的事务分支
阶段2：TM 根据阶段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 方法执行，因此插入一条 status=4 状态的记录，当一阶段 Try 方法后面执行时，判断 status=4 ，则说明有二阶段 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次后不再通知，允许消息丢失（不可靠消息）
- 定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询（主动方提供查询接口），恢复丢失的业务消息