1分布式事务的实现策略和模式
学习目标
- 分布式事务基本特性
- 分布式事务常见实现模式
分布式事务是一种基础设施
目录
基本概念
确保分布式系统数据一致性
分类：两阶段 /三阶段提交
- 两阶段基本思想
2PC Two-Phase Commit 多参与者投票，协调者根据投票决定commit/abort，全票通过才commit
两阶段提交实现方案需解决的问题：同步阻塞问题、单点故障问题、数据不一致问题 - 三阶段
协调者 询问 参与者 CanCommit?
协调者 PreCommit
协调者 收到参与者PreCommit ACK
协调者 DoCommit
协调者 收到参与者Committed返回
三阶段提交：超时机制参与者无法及时收到来自协调者的信息就会默认执行提交，不会一直持有事务资源并处于阻塞状态。
传统分布式事务（2,3阶段）的问题
分布式数据一致性面对的问题
- 锁定资源是昂贵操作，性能影响大
- 服务使用不同的数据库
- 服务之间隔离，通过API访问
CAP理论
| 组合 | Description |
|---|---|
| CA | 放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择 (ACID关系型数据库) |
| AP | 放弃一致性(这里说的一致性是强一致性)追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NOSOL系统就是如此 |
| CP | 放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用 |
分区：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。
分区容错性：在集群出现分区时，整个系统也要持续对外提供服务
可用性针对节点出现故障，系统可用；
分区容错性针对网络出现问题，系统可用
BASE
- 基本可用 Basically Available
- 软状态 Soft State
允许数据存在中间状态，提高灵活性和响应速度，尤其在网络分区时 - 最终一致性 Eventual consistency
BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性，应用可以采用适合的方式达到最终一致性
补偿类实现模式
补偿服务来协调各个需要保证一致性的服务，补偿服务按顺序调用服务，如果某个服务失败就撤销已完成的服务。在这个过程中，补偿服务对需要保证一致性的微服务提供补偿操作。
补偿范围：对于补偿服务而言，记录所有微服务的操作记录和日志是一个关键点，这些记录和日志有助于确定失败的步骤和状态，从而明确需要补偿的范围
分类
不同模式对两阶段三阶段实现不同
- AT
- TCC
- Saga（不常用）
事件/编排式Saga事务，命令/协同式Saga
引入补偿框架实现补偿服务
补偿框架提供服务编排和自动完成补偿的能力。
AT
一阶段执行完成释放本地锁
二阶段执行完成释放全局锁
数据一致性弱
简单业务场景适用事务消息+日志补偿+跑批补偿
分布式事务性能，部署，维护成本高
一阶段
开发简单（优先选择），性能差一点(启动全局锁)
解析sql、生成undolog、执行sql二阶段
事务成功则释放锁，失败则通过undolog回退
TCC
不会施加全局锁，相对AT灵活，复杂，性能较高
TCC 两阶段，从服务提供三个接口try/confirm/cancel，自定义提交/回滚，
Saga
长事务，灵活、时效性差（不推荐）
比如优惠卷业务已使用，一段时候后需要回滚？
- 事件/编排式Saga事务
一般引入消息中间件，通过事件发送方式控制，事务1完成发送事务2开始消息 - 命令/协同式Saga
事务管理器协调事务执行
XA
强一致性，金融级
其他类型实现模式
- 可靠事件模式
引入消息中间件，基于消息通信的可靠性 - 最大努力通知模式
通知类实现模式
查询组件、通知组件、确认组件 - 人工干预模式
兜底方案
思考题
在日常开发过程中，你使用或接触过哪些分布式事务的实现模式?
（使用什么分布式事务技术？什么场景？如何选型？优势劣势？特性？）