分布式事务
联系一致性算法章节看
理解CAP和BASE CAP:一致,可用,分区容忍 BASE:BA基本可用,SE柔性状态,E:最终一致性
柔性事务
- 两阶段型、
- 对应技术上的 XA、JTA/JTS
- 概括:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作
- 二阶段提交的步骤
- 协调者发送 Prepare 消息
- 每个参与者要么直接返回失败(如权限验证失败),要么在本地执行事务,写本地的 redo 和 undo 日志,但不提交
- 参与者根据协调者的指令执行提交或者回滚操作
- 问题:
- 十分依赖协调者,协调者有问题所有参与者都将阻塞
- 脑裂问题,局部参与者收到消息
- 数据状态不确定:当一条事务被提交但是协调者和参与者都挂了,没人知道事务的状态
- 三阶段提交的步骤
- 引入超时机制,
- 新增中间阶段:canCommit preCommit, doCommit阶段
- 协调者发送commit请求,参与者都返回yes才能执行pre,如果有一个返回no或者超时pre都不能执行,第二阶段就是precommit,预执行完成后执行最后的docommit(主要包含:协调者提交请求,参与者提交事务,参与者返回事务执行结果,执行者确定完成事务)
- pre:确定各个节点最终状态;引入超时,如果超时则进行abort。如果所有节点返回ack。执行续后阶段docommit
- 补偿型、
- TCC 型事务(Try/Confirm/Cancel)可以归为补偿型
- 基于补偿的 long-running 的事务处理模型
- long-running: 持久性,可中断可恢复,异步,并发控制
- 服务器A发起事务,B参与事务;如果A,B都顺利执行则事务执行完成
- 如果B执行事务异常,A已经提交,需要A进行操作的反操作;回滚

- 基于补偿的 long-running 的事务处理模型
- TCC 型事务(Try/Confirm/Cancel)可以归为补偿型
- 异步确保型、
- rocketmq实现的分布式事务,大体就是本地事件判断是否投递的方式,B的事务通过消息队列进行保证
- 1,预提交给mq。
- 本地事务
- 正式提交
- 此阶段B模块可以正式消费事件

- rocketmq实现的分布式事务,大体就是本地事件判断是否投递的方式,B的事务通过消息队列进行保证
- 最大努力通知
- 分布式要求最低允许在达到最大重试次数之后正常结束事务。
