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