上一篇：Sentinel实现热点词限流 | 带你读《Spring Cloud Alibaba（2019）》之十七
下一篇：SpringCloud 解决分布式事务的两种方式 | 带你读《Spring Cloud Alibaba（2019）》之十九
本文来自于《精通Spring Cloud Alibaba》课程的整理，讲师为余胜军，点击查看视频内容。
本文系志愿者整理，供配合学习中心课程使用，不做商业用途。
分布式事务产生的背景
分情况来定。
1、在单体的项目中，多个不同业务逻辑都是在同一个数据源中实现事务管理，是不存在分布式事务此时出现异常会直接抛出，用户体验不好，可以此时问题，因为同一数据源的情况下都是采用事务管理器，相当于每个事务管理器对应一个数据源。
2、在单体的项目中，有多个不同的数据源，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理：解决方案jta+ Atomikos
3、在分布式/微服务架构中，每个服务都有自己的本地的事务，每个服务本地事务互不影响，那么这时候也会存在分布式事务的问题。
事务的定义
对我们的业务逻辑可以实现提交或者回滚，保证数据的一致性的情况。
所以要么提交，要么回滚。
ACID
A原子性：要么提交 要么回滚
C一致性
I隔离性：多个事务在一起执行的时候，互不影响；
D持久性：事务一旦提交或者回滚后，不会在对该结果有任何影响
Rpc通讯中产生的分布式事务的问题原因
- 调用方（订单服务）调用完rpc接口之后，突然程序抛出异常，调用方的事务回滚了，但是被调用方接口没有回滚。
订单服务回滚了，派单成功，在每个jvm中都有自己的本地事务，每个事务都互不影响。 - 被调用方（派单服务）的接口失败的话，调用方可以根据返回的结果，手动回滚调用方本地事务
解决分布式事务的最大核心是什么？
- 最终一致性 在分布式系统中， 因为rpc通讯是需要时间的，短暂的数据一致这是允许的，但是最终数据一定要保持一致性；
- 全局协调者
Base与CAP理论
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
一致性C：在分布式系统中，同一时刻所有的节点的数据都是相同的；
可用性A： 集群中部分节点出现了故障，集群的整体也能够给响应；
分区容错性P：分区容错性是指系统能够容忍节点之间的网络通信的故障，意味着发生了分区的情况，必须就当前操作在C和A之间做出选择；
CP：当你网络出现故障之后，只能保证数据一致性，但是不能保证可用性； zk
AP：当你网络出现故障之后，不能保证数据一致性，但是能够保证可用性 eureka
zk集群中所有的写的请求统一交给我们的领导实现，领导将数据写完后，在同步给每个从节点。
每个节点之间的数据同步需要保持数据一致性的问题。
Zk将数据写入完毕之后，zk是如何将数据同步给每从节点保持数据一致性呢
第一节点 准备节点 zk领导会给每个从节点发一个通知，是否可以同步该数据
所有的从节点回复给zk领导同步数据。
第二节点 zk领导收到zk从节点回复的可以同步数据的话，再直接将数据同步给每个从节点。
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写
目前主流分布式解决框架
- 单体项目多数据源 可以jta+ Atomikos
- 基于rabbitmq的形式解决 最终一致性的思想
- 基于rocketmq解决分布式事务 采用事务消息
- LCN采用lcn模式 假关闭连接 （目前已经被淘汰）
- Alibaba的Seata 未来可能是主流 背景非常强大
两阶段提交协议基本概念
两阶段提交协议可以理解为2pc，也就是分为参与者和协调者，协调者会通过两次阶段实现数据最终的一致性的。
2PC和3pc的区别就是解决参与者超时的问题和多加了一层询问，保证数据的传输可靠性。
