paxos协议_一步一步理解paxos算法_raft paxos

在过去十年里，Paxos基本成为了分布式领域内一致性协议的代名词。Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：“所有一致性协议本质上要么是Paxos要么是其变体”。Paxos是几乎所有相关课程必讲内容以及很多其它一致性协议的起点，Paxos的提出者LeslieLamport也因其对分布式系统的杰出理论贡献获得了2013年图灵奖。

除了其基础性和重要性之外，Paxos也一直以难以理解闻名。Lamport最初的论文晦涩难懂，很少有人能够透彻理解其精髓，直到之后一系列试图以简明清晰讲解Paxos机制的论文发表后此现象才得以缓解。由此带来的一个副作用是：在根据Paxos原理构造实际可用系统时有一定程度的困难，很多声明基于Paxos原理构造的系统在实现时往往会引入开发者自己的理解，这造成的后果是尽管Paxos在理论上可以证明其正确性，但是实现时经过改造的一致性协议并不能保证这一点。Burrows也曾说过：“Paxos算法描述和真实实现之间存在巨大鸿沟……所以最终系统很可能是基于一个未经证明的一致性协议”。

本节讲述Paxos协议，首先介绍副本状态机模型，之后介绍Paxos的一些基本概念，然后描述Paxos协议本身内容。其实从协议内容本身来看很好理解其运作机制，好像体会不到其难理解性，这里需要强调的是：Paxos的难理解性在于是什么因素导致协议以此种方式呈现以及其正确性证明过程而非最终协议内容本身，鉴于其复杂性和篇幅原因，对其感兴趣的读者可参考文献9、10、11，本节以描述其本身机制为主。

|2.4.4.1副本状态机模型(Replicated State Machines)

在分布式环境下，一致性协议的应用场景一般会采用副本状态机来表达，这是对各种不同应用场景的一种抽象化表述。

一种典型的实现副本状态机的机制是采用Log副本的方式（参考图2-20）。集群中多台服务器各自保存一份Log副本及内部状态机，Log内顺序记载客户端发来的操作指令，服务器依次执行Log内的指令并将其体现到内部状态机上，如果保证每台机器内的Log副本内容完全一致，那么对应的状态机也可以保证整体状态一致。一致性协议的作用就是保证各个Log副本数据的一致性，比如图2-20中的一致性模块（Consensus Module）即起此作用。某台服务器在接收到客户端的操作指令后，将其追加到自身的Log尾部，然后和其它服务器的一致性模块进行通信，保证其它服务器（即使是有服务器发生故障）的Log最终能够以同样的顺序保存同样的操作指令，当操作指令能够正确复制，那么每台服务器按照Log内记录顺序执行操作指令，最终所有服务器的内部状态保持一致，服务器将执行操作命令后的状态结果返回客户端作为操作结果。即通过这种方式使得整个集群对于外部客户端看起来就像单机一样。

在实际实现上述副本状态机中的一致性协议时，往往追求以下几个特性：

1. 安全性（Safety）保证：即非拜占庭模型（此概念参考下节内容）下，状态机从不返回错误的结果，多个提议中只会有一个被选中；

2.可用性（Available）保证：只要大多数服务器正常，则整个服务保持可用。比如副本状态机有5台服务器，那么最多可以容忍2台服务器发生故障，此时整个服务仍然可用，即对于2f+1台副本状态机的配置，最多可容忍f个状态机失效；

一般情况下，大多数状态机维护Log一致即可快速通知客户端操作成功，这样避免了少数最慢的状态机拖慢整个请求响应速度。

|2.4.4.2 Paxos基本概念

Paxos又可以细分为两种：单Paxos（Single-Decree Paxos）和多Paxos(Multi-Paxos)。对照上节的副本状态机模型，直观上可以如此理解两者的差异：所谓单Paxos，即副本状态机中各个服务器针对Log中固定某个位置的操作命令通过协议达成一致，因为可能某一时刻不同服务器中Log中相同位置的操作命令是不一样的，通过执行协议后使得各个服务器对应某个固定位置的操作命令达成一致。而多Paxos则是指这些服务器对应的Log内容中多个位置的操作命令序列通过协议保持一致。多Paxos往往是同时运行的多个单Paxos协议共同执行的结果，后文讲解Paxos协议主要以单Paxos为主，这点需要读者注意。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-29829-1.html