分布式事务

前言

最近用到分布式，不可避免使用到分布式事务，正好对分布式事务做一下总结

分布式中常用原理

• CAP原理
• ACID
• BASE

CAP原理

所有分布式都要遵循CP或者AP 原则。分布式设计时必须考虑问题，CAP是什么？

• C(Consistent): 一致性，在同一集群、同一时间点每个节点数据都是一致的。强一致性和最终一致性
• A(Avaliablity): 可用性。指服务一致可用，在规定的时间内完成响应
• P(Partition tolerance): 分区容错性，当分布式系统在遇到节点或网络故障的时候，仍然能够对外提供服务

CAP 无法同时满足，只能满足CP/AP. 分布式集群首先要保证分区容错(Partition tolerance)，如果P不能满足，就是一个单节点。看下面模型

客户端访问serverA, A服务是集群模型有两个分区Partition， node1,node2

• 客户端访问serverA时，两个节点作为一个整体，对外提供服务。如果node1向node2同步数据时，允许发生故障，如果保证Avaliablity 可用性，一个节点出现异常，客户端既可以访问node1，也可以访问node2，仍然可向外提供服务。但是两者数据不一直，不能保证一致性，此时保证的是AP
• 如果保证一致性Consistent，客户端访问任务一个节点数据是一直的。node1向node2 同步数据，发生故障，一直会等待数据同步完成，才能向外提供服务，满足了C不能满足A

分析得出，分布式首先满足分区容错，A,C 只能满足一个，CAP无法同时满足。

ACID

ACID是关系型数据提供的事务机制，但是对于分库分表，ACID无法满足的。 强调数据的强一致性，保证数据CP。

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

• 典型应用

1. 基于XA协议的两阶段提交事务
2. 事务补偿机制都

BASE原理

• Basically Available（基本可用）：基本可用指的是分布式系统在出现故障的时,允许损失部分可用性，即保证核心业务可用，比如电商大促的时候，为了应对激增的访问量，部分用可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现
• 软状态（Soft State）：软状态是指中间状态，中间状态不会影响系统的整体可用性，分布式存储中一般一份数据至少会有两到三个副本，允许不同节点间副本同步的延时就是软状态的体现，mysql replication的异步复制也是一种软状态的体现。
• Eventually consistent（最终一致）：指系统中所有数据副本经过一定时间后，最终达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况

BASE与ACID正好相反。强调是弱一致性，最终一致性，遵行AP 原理。在分布式中大多都是BASE 原理，允许一段时间内暂时牺牲一致性，首先保证系统可用，最终数据一致即可。

• 典型应用：

1. 基于本地消息表
2. 基于MQ的最终一致性方案

分布式事务

• 基于XA协议的两阶段提交
• 事务补偿机制TCC
• 基于本地消息表+定时任务的最终一致性方案
• 基于MQ的最终一致方案
• 基于服务中间件的方式

XA两阶段协议的分布式事务方案

• 什么是两阶段

两阶段即2PC，是指将整个事务流程分为两个阶段，准备阶段Prepare phase，提交阶段Commit phase，2是指两个节点，P是准备节点，C是提交阶段

• XA方案

• XA是由X/Open组织提出的分布式事务的规范
• 整体是由一个事务管理器（TM）和多个资源管理器（RM）组成

1. RM一般就是数据库
2. TM相当于程序中的数据源

• 提交分为两个阶段：Prepare 和 Commit

• 第一阶段

TM告诉所有数据源要进行准备，数据源全部返回Ready进入第二阶段进行commit，一旦在准备阶段如何一个节点出现了问题都会返回错误给TM，TM就会给Ready的数据源发出回滚的命令

• 第二阶段

在第二阶段 commit阶段，如果第二个数据源出现问题没有提交成功会返回一个状态到TM，而第一个已经完成commit就不能回滚了，这个时候就需要人工介入进行干预了

XA两阶段提交总结：

• 保证了数据的强一致性
• commit阶段出现问题，事务出现不一致，需要人工处理
• XA方式效率比较低，性能与本地事务相差了近10倍
• MySQL v5.7及以上版本才支持XA
• mysql-connector-java驱动v5.0以上版本支持XA协议
• Java驱动实现中，数据源采用Atomikos充当TM角色

基于TCC事务补偿方案

TCC 分别是Try，Confirm，Cancel

• 每个操作都要有与之相应的补偿(撤销)处理操作
• 执行失败后，调用补偿进行回滚
• 补偿失败时，需要循环补偿，设置补偿次数，超过后，人工介入处理。可以用使用MQ中死信队列

基于本地消息表方案

• 采用BASE原理，保障事务最终一致
• 在一致性方面，允许一段时间内的不一致，但最终会一致
• 在实际的系统中，要根据具体情况，判断是否需要采用本地消息表方案进行设计
• 基于本地消息表的方案中，将本事务外的操作，记录在消息表中

场景
订单、支付
订单存储业务表，支付信息存储消息表，通过外部服务完成支付后回调修改消息表状态，定时轮询消息表支付状态，修改订单状态。

• 优缺点

• 核心思想是将分布式事务拆分成本地事务进行处理，每一步只操作一个数据库保证自己的事务完整性
• 避免了分布式事务，实现了最终一致性

• 需要注意接口数据的回调状态
• 定时任务处理的幂等性操作

基于消息队列MQ的最终一致性的方案

适用于同一组织/结构，不同组织或结构本地方法表比较合适