关于分布式事务的理解

业务场景

电商业务

上图是一个电商系统，当一个订单支付完成后的业务场景：

1. 更改订单的状态为 “已支付”
2. 扣减商品库存
3. 给会员增加积分
4. 创建出库单通知仓库发货

想象一下，当订单支付完成后，个人积分延迟几分钟变更，这可以接受吗？

火车票购票

想想生活中火车票购票场景。

想象一下，当最后一张火车票同时被两个人购买，去检票口检票时被告知车票无效，这可以接受吗？

银行转账

想想生活中银行转账场景。

想象一下，当银行转账时，转账成功后，自己账户金额减少了，对方账户却一直未进账，这可以接受吗？

关于上述的三种业务需求场景，你是怎么理解和处理的？

在处理上述问题之前，咱们先来理解以下几个概念。

什么是事务？

事务是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。

数据库事务大家肯定都很熟悉，在开发过程中会经常使用到。

事务的特性

• Atomicity(原子性)
• Consistency(一致性)
• Isolation(隔离性)
• Durability(持久性)

原子性 是指事务中的操作要么都不做，要么就全做。

一致性 是指事务必须是使数据库从一个一致性状态变到另一个一致性状态。

隔离性 是指一个事务的执行不能被其他事务干扰。

持久性 是指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

什么是分布式事务？

分布式事务是指一次大的操作由不同的小操作组成的，而这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么完全地执行，要么完成地不执行。

产生分布式事务的原因

• 业务的微服务化，例如：文章开头所描述的电商业务场景。
• 数据库分库分表，例如：当发生数据库分库分表后，有一个需求既要操作 01 库，又要操作 02 库。

分布式理论

CAP 理论

• Consistency(一致性)
• Availability(可用性)
• Partition tolerance(分区容错性)

一致性 是指数据的强一致性，如果在某个节点更新了数据，那么在其他节点需要同时看到更新后的数据。

可用性 是指每个请求都能在合理的时间内获得符合预期的响应结果。

分区容错性 是指遇到任何网络分区故障的时候，系统仍然能够正常提供服务，除非是整个网络环境都发生了故障。

CAP 理论认为一个分布式系统最多只能同时满足其中的两项。由于分区容错性是必然存在的，所以大部分分布式软件系统都在 CP 和 AP 中做取舍。

例如：Zookeeper 采用 CP 一致性，强调一致性，弱化可用性，Eureka 采用 AP 可用性，强调可用性，弱化一致性。

BASE 理论

• Basically Available(基本可用)
• Soft state(软状态)
• Eventually consistent(最终一致性)

基本可用 是指不追求强可用性，而且强调系统基本能够一直运行对外提供服务。当分布式系统遇到不可预估的故障时，允许一定程度上的不可用，比如：对请求进行限流排队，对非核心服务进行降级。

软状态 是指允许系统中的数据存在中间状态，而不是事务的原子性：要么全部成功，要不全部不成功。

最终一致性 是指数据不可能一直都是软状态，必须在一个时间期限之后达到各个节点的一致性，在此之后，所有的节点的数据都是一致的，系统达到最终一致性。

BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

解决方案

2PC(两阶段提交协议)

3PC(三阶段提交协议)

TCC

本地消息表

RocketMQ 事务消息

小结

本文纯属抛砖引玉，有问题，欢迎批评指正。

关于分布式事务的可落地方案，我会在后续文章中进行介绍。

推荐阅读

• 关于处理电商系统订单状态的流转，分享下我的技术方案（附带源码）
• 我是怎么写 Git Commit message 的？