1.CAP

★一致性（2PC、3PC、Paxos、Raft）

●强一致性：数据库一致性，牺牲了性能

ACID：原子性、一致性、隔离性、持久性

●弱一致性：数据库和缓存，延迟双删、重试

●单调读一致性：缓存一致性，ID或者IP哈希

●最终一致性：边缘业务，消息队列

★可用性（多级缓存、读写分离）

●BASE 基本可用：限流导致响应速度慢、降级导致用户体验差

✮Basically Availabe 基本可用

✮Soft state 软状态

✮Eventual Consistency 最终一致性

✮分区容忍性（一致性Hash解决扩缩容问题）

 

2.一致性

 

2PC协议：两阶段提交协议，P是指准备阶段，C是指提交阶段

●准备阶段：询问是否可以开始，写Undo、Redo日志，收到响应

●提交阶段：执行Redo日志进行Commit，执行Undo日志进行Rollback

 

3PC协议：将提交阶段分为CanCommit、PreCommit、DoCommit三个阶段

●CanCommit：发送canCommit请求，并开始等待

●PreCommit：收到全部Yes，写Undo、Redo日志。超时或者No，则中断

●DoCommit：执行Redo日志进行Commit，执行Undo日志进行Rollback

 

区别是第二步，参与者自身增加了超时，如果失败可以及时释放资源

 

3.Paxos算法

参与者（例如Kafka）的一致性可以由协调者（例如Zookeeper）来保证，协调者的一致性就只能由Paxos保证了

 

Paxos算法中的角色：

●Client：客户端、例如，对分布式文件服务器中文件的写请求。

●Proposer：提案发起者，根据Accept返回选择最大N对应的V，发送[N+1,V]

●Acceptor：决策者，Accept以后会拒绝小于N的提案，并把自己的[N,V]返回给Proposer

●Learners：最终决策的学习者、学习者充当该协议的复制因素

Q：如何保证Paxos算法活性

A：假设存在这样一种极端情况，有两个Proposer依次提出了一系列编号递增的提案，导致最终陷入死循环，没有value被选定

●通过选取主Proposer，规定只有主Proposer才能提出议案。只要主Proposer和过半的Acceptor能够正常网络通信，主Proposer提出一个编号更高的提案，该提案终将会被批准。

●每个Proposer发送提交提案的时间设置为一段时间内随机，保证不会一直死循环

 

4.Raft算法

Raft 是一种为了管理复制日志的一致性算法

 

Raft使用心跳机制来触发选举。当server启动时，初始状态都是follower。每一个server都有一个定时器，超时时间为election timeout（一般为150-300ms），如果某server没有超时的情况下收到来自领导者或者候选者的任何消息，定时器重启，如果超时，它就开始一次选举。

 

Leader异常：异常期间Follower会超时选举，完成后Leader比较彼此步长

 

Follower异常：恢复后直接同步至Leader当前状态

 

多个Candidate：选举时失败，失败后超时继续选举