分布式事务

CAP & Raft原理

CAP

一致性（consistency）（弱一致，强一致，最终一致）
可用性（Availability）部分故障，整体可用，主要考虑时延，不让用户等待太久（年容忍停机时间，可用水平）
分区容错性（Partition tolerance）部分故障时，对外提供一致性和可用性的服务，分布式基本要求

分布式一致性 CP

一个节点有三种状态（随从、候选者、leader），如有三个节点，启动都会以随从启动，节点1变为候选者，发动投票，申请为领导，多数同意即可成功，所有请求通过领导，保存到节点日志，日志发送给随从，收到大多数回复，领导commit，通知随从commit
Raft，有两个超时时间，1、随从申请领导，如果150-300ms无领导命令，随从变候选人，节点投票变领导，发送日志给随从，2、领导跟随从维护一个心跳超时链接
如果两个节点同时成为候选，投票分离，各获得2票，重新自旋，发起投票，直到选出领导
网络分区形成两个领导后，分区恢复，低阶领导跟随高阶领导，低阶随从回滚数据
如果一分为二，永远选不出领导，导致业务不可用

BASE理论–最终一致性

基本可用，损失部分可用性，用户可能等待或者报忙碌让重试
软状态，中间状态，允许同步延时
最终一致

分布式可用性 AP

分布式几种方案

2PC模式

如果链接两个数据库，收到两个数据库确认能提交的回复后再发起提交

柔性事务–TCC事务补偿

Try-Confirm-Cancel，最终一致性，所有数据库完成try后再执行confirm

柔性事务–最大努力通知方案

反复通知，直到收到，使用消息队列

柔性事务–可靠消息+最终一致性方案–异步确保