分布式事务

分布式事务

集群下保证事务的一致性
分布式条件下,多个节点操作的整体事务的一致性
实现的方法:

1. 强一致性:像但数据库一样,多个数据库自动通过某种机制,实现跨数据节点的一致性

• XA

2. 柔性事务:可以容忍一段时间的数据不一致,最终通过超时中止,调度补偿().

• 不用事务,业务侧补偿冲正
• 所谓的柔性事务,使用一套事务框架()对代码侵入性小保证最终一致的事务

XA分布式事务

基于第一个强一致的思路,就有了基于数据库本身支持的协议，XA分布式事务。
XA分布式事务协议:

1. 应用程序:用于定义事务边界(即定义事务的开始和结束),并且在事务边界内对资源进行操作.
2. 资源管理器:如数据库,文件系统,并提供访问资源的方式(资源之间不相互通信)
3. 事务管理器:负责分配事务唯一标识,监控事务的执行进度,并负责事务的提交,回滚.
4. 支持XA的框架:atomikos
5. XA事务协议

• xa_start:负责开启或恢复一个事务分支
• xa_end:负责取消当前线程与事务分支的关联
• xa_prepare:询问RM是否准备好提交事务分支
• xa_commit:通知RM提交事务分支
• xa_rollback:通知RM回滚事务分支
• xa_recover:需要恢复的XA事务

BASE柔性事务

1. base是基本可用,柔性状态和最终一致性的缩写

• 基本可用,保证分布式事务参与方不一定同时在线
• 柔性状态:允许系统状态更新有一定的延时,这个延时对客户来说不一定能察觉
• 最终一致性:通常是通过消息传递的方式保证系统的最终一致性

2. 柔性事务的理念是通过业务逻辑将互斥锁操作从资源层面上移至业务层面上,
3. 常见的柔性事务:tcc/at

TCC/AT以及相关框架

TCC

tcc模式将每个服务业务操作分成两个阶段,第一个阶段检查并预留相关资源,第二个阶段根据所有服务业务的try状态来操作,如果都成功,则进行confirm操作,如果任意一个try发生错误,则全部cancel

1. 准备操作Try:完成所有业务检查,预留必须的业务资源
2. 确认操作Confirm:真正执行的业务逻辑,不做任何业务检查,只是用try阶段的业务资源,因此,只要try成功,confirm必须能成功.
3. 取消操作cance:释放try阶段预留的业务资源,同样的,cancel操作也需要满足幂等

SAGA

saga模式没有try阶段,直接提交事务

AT

AT模式就是两阶段提交,自动反向生成反向sql