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

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。