paxos

Basic Paxos 总的来说，Basic Paxos分成四个角色，俩个步骤，分别是 角色： 1.Client 　　Client发送一个请求到分布式系统，比如请求一个文件 1.Proposer 　　Proposer接收客户端的请求，并且让Acceptors接受这个请求。当发送冲突时，担任协调者。 2.Acceptors 　　一组Acceptors组成法定人数(一群Acceptors)，任何发送给Acceptors的消息都必须发送给法定人数，从Acceptors收到的任何消息都应该忽略， 　　除非从法定人数内的每个Acceptors都收到一份同样的消息。 3.Learner 　　Learner充当协议的复制者，一旦Client的请求被Acceptors通过，Learner就可以执行客户端的请求（执行请求，响应数据给Client），为了保证可用性，Learner可以动态添加。 上面三个角色，任何一个参与者都可以扮演任意角色，但是在一轮共识过程中，只能担任一个角色（在共识形成后Learner才有作用）。 4.Leader 　　Paxos需要一个Proposer充当Leader来管理过程。但是可能有多个Proposer相信自己是Leader，协议保证只选择其中的一个，如果有多个Leader，就会出现冲突更新。 Quorums Quorums 表示法定人数，任何俩组法定人数

Paxos Paxos总共有三个角色 1:提议者（Proposers） 2:接受者（Acceptors） 3:学习者（Learns） 一致性的目标是一组参与者在每次商议中对一个值形成共同的共识。 从Propsers提交值给一组Acceptors开始就开启一次一致性商议，Acceptors在接受某次提案的值，并且超过某次阀值后，这个值就会在网络中传播。 为了让Paxos协议能正常工作，第一个约束是： Acceptors必须接受它收到的第一个提案的值。 这会导致一个问题，考虑一下这个情况，多个Proposers发送提案的值，多个Acceptors接收到多个值。因为Acceptors只接收第一个收到的值，所以形成不了 大多数结果。Paxos给每次的提案附加唯一的标记来允许Acceptors同时接收到多个提案。 对每次提案附加一个唯一标记，某次提案过程中，如果大多数Acceptors接受提案的值，这个值就叫做chosen value。可以通过多个提案，但是必须保证 多个提案对于同一个值有相同的值。这样就引出第二个约束： 如果已经选择了提案的值 V，每次更高的提案都必须选择值 V。 网络通讯异步进行，所以会存在某些Acceptors未收到chosen value，但是这个并不会违反约束1和约束2. Propsers在发送消息给acceptors时使用如下几个约束。这个过程叫做prepare

参考： Paxos协议基本原理， http://blog.csdn.net/malefactor/article/details/51365744 微信PaxosStore：深入浅出Paxos算法协议， http://www.infoq.com/cn/articles/wechat-paxosstore-paxos-algorithm-protocol 分布式一致性算法--Paxos， https://www.cnblogs.com/cchust/p/5617989.html 前言 Paxos 一致性协议可以说是一致性协议研究的起点，也以难以理解闻名。其实协议本身并没有多难理解，它的难理解性主要体现在：为何如此设计协议以及如何证明其正确性。本文尝试通过流程图来说明协议的内容以及基本应用过程，不涉及如何证明其正确性。 基本概念 Paxos 可以分为两种： Single-Decree Paxos ：决策单个 Value Multi-Paxos ：连续决策多个 Value，并且保证每个节点上的顺序完全一致，多 Paxos 往往是同事运行多个单 Paxos 协议共同执行的结果。 本文只关注单 Paxos 的原理，理解了单 Paxos，多 Paxos 也就不难理解了。 Paxos 协议中的三种角色 倡议者（Proposer） ：倡议者可以提出提议（数值或者操作命令）以供投票表决 接受者

分布式设计与开发中有些疑难问题必须借助一些算法才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

分布式设计与开发中有些疑难问题必须借助一些 算法 才能解决，比如分布式环境一致性问题，感觉以下分布式算法是必须了解的（随着学习深入有待添加）： Paxos算法 一致性Hash算法 Paxos算法 1）问题描述 分布式中有这么一个疑难问题，客户端向一个分布式集群的服务端发出一系列更新数据的消息，由于分布式集群中的各个服务端节点是互为同步数据的，所以运行完客户端这系列消息指令后各服务端节点的数据应该是一致的，但由于网络或其他原因，各个服务端节点接收到消息的序列可能不一致，最后导致各节点的数据不一致。举一个实例来说明这个问题，下面是客户端与服务端的结构图： 当client1、client2、client3分别发出消息指令A、B、C时，Server1~4由于网络问题，接收到的消息序列就可能各不相同，这样就可能由于消息序列的不同导致Server1~4上的数据不一致。对于这么一个问题，在分布式环境中很难通过像单机里处理同步问题那么简单，而Paxos算法就是一种处理类似于以上数据不一致问题的方案。 2）算法本身 算法本身我就不进行完整的描述和推导，网上有大量的资料做了这个事情，但我学习以后感觉莱斯利·兰伯特（Leslie Lamport，paxos算法的奠基人，此人现在在微软研究院）的 Paxos Made Simple 是学习paxos最好的文档

Zookeeper使用了一种称为Zab（Zookeeper Atomic Broadcast）的协议作为其一致性复制的核心，据其作者说这是一种新发算法，其特点是充分考虑了Yahoo的具体情况：高吞吐量、低延迟、健壮、简单，但不过分要求其扩展性。下面将展示一些该协议的核心内容： 另，本文仅讨论Zookeeper使用的一致性协议而非讨论其源码实现 Zookeeper的实现是有Client、Server构成，Server端提供了一个一致性复制、存储服务，Client端会提供一些具体的语义，比如分布式锁、选举算法、分布式互斥等。从存储内容来说，Server端更多的是存储一些数据的状态，而非数据内容本身，因此Zookeeper可以作为一个小文件系统使用。数据状态的存储量相对不大，完全可以全部加载到内存中，从而极大地消除了通信延迟。 Server可以Crash后重启，考虑到容错性，Server必须“记住”之前的数据状态，因此数据需要持久化，但吞吐量很高时，磁盘的IO便成为系统瓶颈，其解决办法是使用缓存，把随机写变为连续写。 考虑到Zookeeper主要操作数据的状态，为了保证状态的一致性，Zookeeper提出了两个安全属性（Safety Property） 全序（Total order）：如果消息a在消息b之前发送，则所有Server应该看到相同的结果 因果顺序（Causal order）

Paxos算法 Paxos算法是解决分布式系统中如何就某个值达成协议。典型的场景就是选举主机，zookeeper选举主机使用的zab算法就是Paxos的一个实现。 Paxos的三个角色 Proposer：提议者，提出方案的角色 Acceptor：接受者，接收方案的角色 Learner：学习者，确定接受者是否超过半数的节点同意某个提案 Paxos分为三个阶段 阶段1：发送编号 每一个提议者都会提供一个编号N，并先半数以上的接受者发送编号。 接受者接收到编号后，用伪代码表示 Integer N_p； //提议者编号 Object V_p ; //提议者提案 Integer N_a ; //接受者编号 Object V_a ; //接受者提案 if ( N_a == null ) { //接收者没有接受过编号 N_a = N_p ; } else if ( N_p < N_a ) { //提议者的编号小于接收者的编号，拒绝提议者的编号 return ; } else { //接受提议者的编号 N_a = N_p ; if ( V_a != null ) { //额外的，如果接受者已经有提案了，那么提议者将自己的提案设置为接受者的提案，否则提议者会在阶段二自己定义提案 V_p = V_a； } } 阶段2：发送提案 提议者再次给接受者发送提案 Integer N_p； //提议者编号

随承载用户数量的增加和容灾的需要，越来越多互联网后台系统从单机模式切换到分布式集群。回顾自己毕业五年来的工作内容，同样有这样的转变。 毕业头两年负责维护运行在刀片机上的业务，在机房里拔插单板的日子是我逝去的青春。设备之间通过VCS组成冷备，但即使有双机软件保护，宕机、网络丢包等问题发生时业务仍会受影响。这样的系统架构下为保证SLA，有时候需要深入Linux系统内核或硬件层面分析机器重启的原因。 接下来负责维护承载在分布式集群上的业务，相比前面的工作，这个阶段主要关注点不是单节点的异常，更多是系统整体的稳定和健壮。面对纷繁复杂的系统，刚开始的时候有这样的感觉： 庞大复杂的分布式系统前，应该从哪方面入手提升对其的认识和理解、提升专业性？网上可以找到很多分布式系统相关的论文和资料，但归纳起来要表达的主要意思是什么？ 结合自己这几年的工作经验，总结分布式系统的核心就是解决一个问题：不同节点间如何达成共识。 看似简单的问题因网络丢包、节点宕机恢复等场景变得复杂，由此才衍生出很多概念、协议和理论。为探究共识问题最大能解决的程度，于是有FLP、CAP边界理论；为在特定条件和范围内解决该问题，于是有一致性协议Paxos、Raft、Zab和Viewstamped Replication；为构建这些协议，于是有多数派、Leader选举、租约、逻辑时钟等概念和方法。

Paxos协议/算法是分布式系统中比较重要的协议，它有多重要呢？ <分布式系统的事务处理> ： Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。 <大规模分布式存储系统> ： 理解了这两个分布式协议之后(Paxos/2PC)，学习其他分布式协议会变得相当容易。 学习Paxos算法有两部分：a) 算法的原理/证明；b) 算法的理解/运作。 理解这个算法的运作过程其实基本就可以用于工程实践。而且理解这个过程相对来说也容易得多。 网上我觉得讲Paxos讲的好的属于这篇： paxos图解 及 Paxos算法详解 ，我这里就结合 wiki上的实例 进一步阐述。一些paxos基础通过这里提到的两篇文章，以及wiki上的内容基本可以理解。 算法内容 Paxos在原作者的《Paxos Made Simple》中内容是比较精简的： Phase 1 (a) A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors. (b) If an acceptor receives a prepare request with number n greater than

在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到 all working protocols for asynchronous consensus we have so far encountered have Paxos at their core. 关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从英文版翻译而是独立写的，所以非常具有互补性。Paxos算法是由Leslie Lamport提出的，他在Paxos Made Simple[4]中写道 The Paxos algorithm, when presented in plain English, is very simple. 当你研究了很长一段时间Paxos算法还是有点迷糊的时候，看到上面这句话可能会有点沮丧。但是公认的它的算法还是比较繁琐的，尤其是要用程序员严谨的思维将所有细节理清的时候，你的脑袋里更是会充满了问号。Leslie Lamport也是用了长达9年的时间来完善这个算法的理论。 实际上对于一般的开发人员，我们并不需要了解Paxos所有细节及如何实现，只需要知道Paxos是一个分布式选举算法就够了