分布式事务

CAP原理

• C-Consistent,一致性.即操作成功后,所有的节点在同一时间看到的数据是完全一致的(数据一致性)
• A-Availability,可用性.指服务一致可用,在规定的时间完成响应
• P-Partition tolerance,分区容错性.指分布式系统在遇到某节点或网络故障的时候,仍能对外提供服务
• CAP原理指出,3个指标不同同时满足,最多满足其中的两个

ACID

• A-Atomicity(原子性),事务中的操作要么都做,要么都不做
• C-Consistency(一致性),系统必须始终处在强一致状态下
• I-Isolation(隔离性),一个事务的执行不能被其它事务锁干扰
• D-Durability(持久性),一个已提交的事务对数据库中数据的改变是永久性的
• ACID强调的是强一致性,要么全做,要么全不做

BASE

• Basically Available(基本可用),指的是分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用.
• Soft State(软状态),指的是允许系统存在中间状态,且该状态不会影响系统整体可用性
• Eventual Consistency(最终一致性),指的是系统中所有数据副本经过一定时间后,最终能够达到一致的状态

基于XA协议的两阶段提交

• 是由X/Open组织提出的分布式事务规范
• 由一个事务管理器(TM)和多个资源管理器(RM)组成
• 提交分为两个阶段:prepare和commit
  • 保证数据的强一致性
  • commit阶段出现问题,事务出现不一致,需要人工处理
  • 效率底下,性能与本地事务相差10倍
• mysql5.7及以上均支持XA协议
• MySQL Connector/J5.0以上支持XA协议
• Java系统中,数据源采用Atomikos

## pom引入片段
<artifactId>spring-boot-starter-jta-atomikos</artifactId>
## 部分配置

事务补偿机制

• 针对每个操作,都要注册一个与其对应的补偿(撤销)操作
• 在执行失败时,调用补偿操作,撤销之前的操作
• 逻辑清晰,流程简单
• 数据一致性比XA还要差,可能出错的点比较多
• 属于应用层的一种补偿方式,程序员需要写大量的代码

基于本地消息表+定时任务的最终一致方案

• 采用BASE原理,保证事务最终一致
• 在一致性方面,允许一段时间内的不一致,但最终会一致
• 将本事务外的操作记录在消息表中
• 其它事务提供操作接口
• 定时任务轮询本地消息表,将未执行的消息发送给操作接口
• 操作接口处理成功,返回成功标识,处理失败返回失败标识
• 定时任务接到标识,更新消息状态
• 对于屡次失败的消息,可以设置最大失败次数
• 超过最大失败次数的消息,不再进行接口调用,等待人工处理
• 避免了分布式事务,实现了最终一致性
• 重试时的幂等性操作要注意

基于MQ的最终一致方案

• 原理,流程与本地消息表类似
• 不同点
  • 本地消息表改为MQ
  • 定时任务改为MQ的消费者
• 不依赖定时任务,基于MQ更高效,更可靠
• 适合于公司内的系统
• 不同公司之间无法基于MQ,本地消息表更合适