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