CAP原理(CAP Theorem)
对于一个分布式系统不能可能同时满足,一致性(Consistency)、可用性(Availability)、分区容错性(Partition Tolerance)。
一致性模型
- 弱一致性(最终一致性:添加新纪录后,立即访问,很有可能访问不到最新的值,但是等一段时间之后,就能获取到新的记录。最终一定能得到一致的值。)
- DNS(Domain Name System)
- Gossip(Cassandra的通信协议)
- 强一致性
- 同步
- Paxos
- Raft(multi-paxos)
- ZAB(multi-paxes)
强一致性算法解决问题
- 分布式系统对容错(fault tolerance)的一般解决办法是使用状态机复制(state machine replication)
- 状态机复制其实就是把状态机变更的日志复制到所有的节点中,这也被称为共识(consensus)算法
- paxos其实就是一个共识算法。系统的最终一致性,不仅需要共识算法,还取决于client的行为
强一致性算法实现思路
- 主从同步
- 实现思路:主从复制,1、Master接受写请求;2、Master复制日志至slave;3、Master等待,直到所有从库返回。
- 问题:一个节点失败,Master阻塞,导致整个集群不可用,保证了一致性,可用性大大降低。
- 多数派
- 实现思路:每次写都保证写入大于N/2个节点,每次读保证从大于N/2个节点中读。
- 问题:在并发环境下,因为每个节点命令执行的顺序无法保证,所以系统正确性无法保证。
Paxos协议
Paxospaxos并不指代一个协议而是一类协议的统称,比较常见的paxos类协议有basic paxos以及multi-paxos。该协议的目的是为了多个参与者达成一致观点。
Paxos中的角色
- Client:民众。系统外部角色,请求发起者。
- Propser:议员。接受Client请求,向集群提出建议(propose)。并在冲突发生时起到调节冲突的作用。
- Accpetor(Voter):国会。接受者和提议投票,只有在形成法定人数(Quorum,一般即为多数派majority)时,提议才会最终被接受。
- Learner:记录员。提议接受者,backup,备份,对集群一致性没什么影响。
Basic Paxos
基本概念
流程为
-
Phase 1a:Prepare
- Propser提出一个提案,编号为N,此N大于这个proposer之前提出提案的编号。请求acceptors的quorum接受。
-
Phase 1b:Promise
- 如果N大于此acceptor之前接受的任何提案编号则接受,否则拒绝。
- Phase 2a:Accept
- 如果proposer判断达到了多数派,proposer会发出accept请求,此请求包含提案编号N,以及提案内容。
- Phase 2b:Accepted
- 如果此accepor在此期间没有收到任何编号大于N的提案,则接受此提案内容,否则忽略。
具体场景下的流程说明
成功流程
Client Proposer Acceptor Learner
| | | | | | |
X-------->| | | | | | Request
| X--------->|->|->| | | Prepare(1)
| |<---------X--X--X | | Promise(1,{Va,Vb,Vc})
| X--------->|->|->| | | Accept!(1,V)
| |<---------X--X--X------>|->| Accepted(1,V)
|<---------------------------------X--X Response
| | | | | | |
上图中,Va,Vb,Vc分别表示三个Acceptor的协议号,Promise过程会将Va,Vb,Vc中最大的一个协议号发回给Proposer。
部分节点失败,但达到了Quorums
Client Proposer Acceptor Learner
| | | | | | |
X-------->| | | | | | Request
| X--