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：选举时失败，失败后超时继续选举
