共识算法(1) - paxos & raft

1. Paxos

   算法的介绍在wikipedia里解释很清楚，可以结合example里的例子加深理解。概括来说，paxos分为prepare和accept两个阶段，将角色分为proposer，acceptor和learner，最基本的标准是majority quorum。每次proposer以（sequence number n, value v）的形式向acceptor提议（n为每个proposer节点自行管理的单增值，注意，这里会有多个proposer在并行的提议）。如果将prepare request到最终accept视作一轮，那么最终accept的提议是来自n最高的proposer，但是v是在prepare阶段最早得到quorum accept的，因为acceptor收到prepare request作出这样的promise（即承诺不再accept比该proposal的n更小或相等的值），并且返回收到并回复的prepare request的值。

   • Paxos (computer science) - wiki
   • Paxos By Example

2. Raft

   大致思路是，raft角色分为leader，follower和candidate（在leader election阶段）。每个leader的当选任期有全局统一且历史递增的term number。所有的写请求被路由或者follow重定向提交到leader，相当于将proposer缩减成唯一一个leader，leader给每个请求log entry添加index。整个过程也分为两个阶段，prepare阶段leader将log entry同步到所有follower，收到majority quorum回复同步后进入commit阶段，leader先commit本地，发送commit消息到follower，并且回复client。follower再commit本地执行，commit该index也意味着之前小于该index的消息都已同步并且全网一致。leader失败后则进入新一轮的选举（term值增加），最新最全数据的节点当选，新leader将其本地数据全网同步，follower相应补充或者剪枝，保证全局数据一致。

   • The Raft Consensus Algorithm : Raft的github page
   • Raft example : 国外的动画，非常形象
   • Understanding the Raft consensus algorithm: an academic article summary
   • Raft 共识算法 ： 可以参看这篇etcd里介绍raft共识算法的节点异常情况

3. 综述

   paxos最早的理论基础，但是工程上实现难度比较大，所以zookeeper（07年）自己设计了zab。13年raft出现，借鉴了zab的设计思想，同时工程上相对paxos更容易实现和理解。这些算法大量用于分布式应用及组件设计，假设前提是没有恶意节点，但并不能解决拜占庭将军问题（Paxos可以针对性扩展为Byzantine Paxos）。

   • 分布式系统的基石：深入浅出共识算法 ： 共识算法的综述，涵盖了paxos，raft，zab
   • Zab vs. Paxos