一致性介绍

Agenda
1.    什么是一致性
a.    CAP theorem
b.    一致性模型
2.    强一致性
a.    Paxos
b.    Raft
c.    ZAB
Detail
1.    什么是一致性
1.1    CAP theorem
对于一个分布式系统，不能同时满足以下三点：
一致性（Consistency）
可用性（Availability）
分区容错性（Partition Tolerance）
 
1.2    一致性模型
弱一致性
最终一致性
DNS（Domain Name System）
Gossip（Cassandra的通信协议）
         强一致性
              同步
              Paxos
              Raft（multi-paxos）
              ZAB（multi-paxos）
 
2.    首先 –明确问题（强一致性解决的问题）
数据不能存在单点上。（鸡蛋不要放在同一个篮子里）
分布式系统对fault tolorence的一般解决方案是state machine reolication。
其实我们今天讨论的准确的说，应该是state machine reolication的共识（consensus）算法。
Paxos其实是一个共识算法。系统的最终一致性，不仅需要达成共识，还会取决于client的行为。
3.    强一致性算法—主从同步
主从同步复制
 
1.    Master接受写请求
2.    Master复制日志至slave
3.    Master等待，直到所有从库返回
问题：一个节点失败，Master阻塞，导致整个集群不可用，保证了一致性，可用性却大大降低
4.    强一致性算的—多数派
基本思想：
多数派！
每次写都保证写入大于N/2个节点，每次读保证从大于N/2个节点中读
多数派还不够！：
在并发环境下，无法保证系统正确性，顺序非常重要。例如：
Inc 5：代表加5；set 0：代表置为0
执行顺序不同，结果不同，前两个是先加5，再置为0，第三个是先置为0，再加5
 
5.    强一致性算法—paxos
Lesile Lamport，Latex的发明者。
为描述paxos算法，Lamport虚拟了一个叫做paxos的希腊城邦，这个岛按照议会民主制的政治模式制定法律，但是没有人愿意将自己的全部时间和精力放在这种事。所以无论是议员，议长或者传递纸条的服务员都不能承诺别人需要时一定会出现，也无法承诺批准决议或者传递消息的时间。
Paxos
Basis Paxos
Multi Paxos
Fast Paxos
6.    强一致性算法—Basic Paxos
角色介绍：
Client：系统外部角色，请求发起者。像民众。（不参与投票）
Propser：接受client请求，向集群提出提议（propose）。并在冲突发生时，起到冲突调节的作用。像议员，替民众提出议案。
Acceptor（voter）：提议投票和接收者，只有在形成法定人数（quorum，一般即为majority多数派）时，提议才会最终被接受。像国会。
Learner：提议接受者，backup，备份，对集群一致性没什么影响。像记录员。（不参与投票）
步骤、阶段（phases）：
1.    Phase 1a：prepare
Proposer提出一个提案，编号为N，此N大于这个proposer之前提出提案编号，请求acceptor的quorum接受。
2.    Phase 1b：promise
如果N大于次acceptor之前接受的任何提案编号则接受，否则拒绝。
3.    Phase 2a：accep
如果达到了多数派，proposer会发出accept请求，此请求包含提案编号N，以及提案内容。
4.    Phase 2b：accepted
如果此acceptor在此期间没有收到任何编号大于N的提案，则接受此提案内容，否则忽略。
Learner可以理解为备份数据，记录过程
 
 
 
 
7.    强一致性算法—Multi Paxos
Basic Paxos的问题：
难实现、效率低（2轮RPC）、活锁
Multi Paxos：
新概念，Leader：唯一的propser，所有请求都需经过此leader。
Leader故障的话，就会重选leader，第N任总统就换为N+1任了。
关键点在于，Multi Paxos有唯一一个proposer，也就是说Multi paxos的prepare只用来竞选总统。Multi paxos只在没有proposer的时候需要竞选。
     

8.    强一致性算法—Raft
Raft
   划分成三个子问题：
       Leader Election
       Log Replication
       Safety
   重定义角色：
       Leader
       Follower
       Candidate
   原理动画解释：http://thesecretlivesofdata.com/raft/
一致性并不一定代表完全正确！
三个可能结果：成功、失败、unknown
Raft 5 nodes example：
Client写请求，leader向followers同步日志，此时集群中有3个节点失败，2个节点存活，结果是？
场景测试：https://raft.github.io/
9.    强一致性算法—ZAB
基本与raft相同。
在一些名词的叫法上有些区别：如ZAB将某一个leader的周期称为epoch，而raft则称为term。
实现上也有些许不同：如raft保证日志连续性，心跳方向为leader至follower。ZAB则相反。