分布式事务几种方案(初识分布式事务)

基础理论

一、CAP

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。 CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

?

二、BASE理论

?

三、事务类型

??1、刚性事务

??遵循 ACID 原则，强一致性

??2、柔性事务

??遵循 BASE 理论，最终一致性与刚性事务不同，柔性事务允许一定时间内，不同节点的数据不一致，但要求最终一致。

模型

一、2PC 模式（刚性事务）

1、介绍

数据库支持的 2PC【2 phase commit 二阶提交】，又叫做 XA Transactions。MySQL 从 5.5 版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

• 其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

  ??其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。

  • 第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是 否可以提交.

  • 第二阶段：事务协调器要求每个数据库提交数据。

?

2、优缺点

• 成本低，维护简单

• XA 性能不理想，特别是在交易下单链路，往往并发量很高，XA 无法满足高并发场景

• XA 目前在商业数据库支持的比较理想，在 mysql 数据库中支持的不太理想，mysql 的 XA 实现，没有记录 prepare 阶段日志，主备切换回导致主库与备库数据不一致。

• 许多 nosql 也没有支持 XA

3、示例的框架

• Seata

二、TCC 事务补偿型方案（柔性事务）

?

1、三阶段介绍

• prepare 阶段主要是对业务系统做检测及资源预留

• commit 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行commit 阶段时，默认commit 阶段是不会出错的。即：只要prepare 成功，commit 一定成功。若commit 阶段真的出错了，需引入重试机制或人工处理。

• rollback 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

2、总结

• 三阶段都调用自定义阶段的业务处理逻辑，即所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

3、优缺点

• 代码侵入性很强，维护成本很高

• 实现难度也不小，回滚策略实现并不简单

• 能够全程自定义行为

• 流量承受能力一般

4、框架

??4.1、Hmily

????Hmily是一个高性能分布式事务tcc开源框架。基于java语言来开发（JDK1.8），支持dubbo，springcloud，motan等rpc框架进行分布式事务。

??4.2、Seata

三、最大努力通知型方案（柔性事务）

1、实现例子

• 按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对。这种方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通知次数后即不再通知。

2、 典型案例

• 微信支付回调

3、优缺点

• 数据一致一般

• 可承受高并发流量

• 有一定的代码入侵性

四、可靠消息+最终一致性方案异步确保型（柔性事务）

1、实现

• 业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才会真正发送。

2、防丢失手段

• 做好消息确认机制（pulisher，consumer【手动 ack】）

• 每一个发送的消息都在数据库做好记录。定期将失败的消息再次发送一 遍

3、优缺点

• 可承受高并发流量

• 最终数据一致性较高

• 有一定的代码入侵性

4、案例基于消息队列完成库存解锁