分布式系统事务解决方案
CAP
概念
C - Consistency (一致性)
A - Availability (可用性)
P - Partition Tolerance (分区容错性，即网络故障的容忍性)
案例
eureka: AP(节点上的数据可能并不是最新的)
ZooKeeper : CP (在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的)
redis: AP (两台集群时候，官方推荐三台可满足一致性，但成本高)
对于服务注册来说，可用性比数据一致性更加的重要，选择AP
总结
AC 不可同存原因： 网络故障是肯定存在的；系统中的某个节点在进行写操作。为了保证 C， 必须要禁止其他节点的读写操作，这就和 A 发生冲突了。如果为了保证 A，其他节点的读写操作正常的话，那就和 C 发生冲突了。
CP: 保证一致性和分区容错，大型集群中网络问题不会导致服务不可用
AP: 保证可用和分区容错，大型集群中网络问题可能导致服务不可用 (只有半数以上一致才算一致，不然就是失败)
BASE 模型
概念
BASE模型 （基本可用） BASE理论是对CAP的延伸和补充，是对CAP中的AP方案的一个补充，即使在选择AP方案的情况下，如何更好的最终达到C。
BASE模型是传统ACID模型的反面，不同与ACID，BASE强调牺牲高一致性，从而获得可用性，数据允许在一段时间内的不一致，只要保证最终一致就可以了。
Basically Available：基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state：软状态可以有一段时间不同步，异步。
Eventually consistent最终一致：最终数据是一致的就可以了，而不是时时一致。
2PC 模式
概念
有一个事务管理器（mysql,sql server,oracle 皆可，使用的 XA transaction协议）来管理所有微服务的事务。
两段式提交模式：第一阶段为准备就绪（所有服务只差commit了），第二阶段为提交， 如果有某个服务出现异常则全部事务回滚。
刚性事务：强一致性，ACID
使用场景少，因为性能不理想。 现在还有3PC，即将第一阶段划分更细，就绪 -> 能否提交 -> 提交
TCC事务补偿方案
概念
柔性事务，BASE，最终一致性。
TCC： try, confirm, cancel. 每一个事务都要写三段代码。
try: 先别直接更新成结果，而是更新成中间态，或者有额外字段存放这次变动的值
confirm：幂等，默认一定会成功，会重试。 更新成结果值
cancel： 幂等，回滚逻辑
引入现成的框架更好，比较要每个去写很麻烦。
TCC 最大努力通知型
概念
最大努力通知：设置通知次数，超过了就不通知了。
使用通知（MQ）来实现回滚逻辑。
解耦了，并且支持大并发的。
案例
下单失败，发消息出去，其他服务订阅消息以做回滚操作
阿里巴巴提供的一套分布式事务解决方案
支持多种模式 XA, AT（自动补偿），TCC
Last updated