业务场景
电商业务
上图是一个电商零碎，当一个订单领取实现后的业务场景：
- 更改订单的状态为“已领取”
- 扣减商品库存
- 给会员减少积分
- 创立出库单告诉仓库发货
设想一下，当订单领取实现后，集体积分提早几分钟变更，这能够承受吗？
火车票购票
想想生存中火车票购票场景。
设想一下，当最初一张火车票同时被两个人购买，去检票口检票时被告知车票有效，这能够承受吗？
银行转账
想想生存中银行转账场景。
设想一下，当银行转账时，转账胜利后，本人账户金额缩小了，对方账户却始终未进账，这能够承受吗？
对于上述的三种业务需要场景，你是怎么了解和解决的？
在解决上述问题之前，咱们先来了解以下几个概念。
什么是事务？
事务是指作为单个逻辑工作单元执行的一系列操作，要么齐全地执行，要么齐全地不执行。
数据库事务大家必定都很相熟，在开发过程中会常常应用到。
事务的个性
- 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 的？