文章目录：
- 业务场景
- 电商业务
- 火车票购票
- 银行转账
- 什么是事务？
- 事务的特性
- 什么是分布式事务？
- 产生分布式事务的原因
- 分布式理论
- CAP 理论
- BASE 理论
- 解决方案
- 2PC(两阶段提交协议)
- 3PC(三阶段提交协议)
- TCC
- 本地消息表
- RocketMQ 事务消息
- 小结
业务场景
电商业务
上图是一个电商系统，当一个订单支付完成后的业务场景：
- 更改订单的状态为 “已支付”
- 扣减商品库存
- 给会员增加积分
- 创建出库单通知仓库发货
想象一下，当订单支付完成后，个人积分延迟几分钟变更，这可以接受吗？
火车票购票
想想生活中火车票购票场景。
想象一下，当最后一张火车票同时被两个人购买，去检票口检票时被告知车票无效，这可以接受吗？
银行转账
想想生活中银行转账场景。
想象一下，当银行转账时，转账成功后，自己账户金额减少了，对方账户却一直未进账，这可以接受吗？
关于上述的三种业务需求场景，你是怎么理解和处理的？
在处理上述问题之前，咱们先来理解以下几个概念。
什么是事务？
事务是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。
数据库事务大家肯定都很熟悉，在开发过程中会经常使用到。
事务的特性
- 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 事务消息
小结
本文纯属抛砖引玉，有问题，欢迎批评指正。
关于分布式事务的可落地方案，我会在后续文章中进行介绍。
