paxos

3 月，跳不动了？>>> 简单的说， Raft 是一种易于理解的一致性算法，其功能相当于Paxos。目前很多提供一致性服务的系统都采用Paxos, 例如Chubby, ZooKeeper, 那么为何还需要 Raft ？自Lamport 1998年提出Paxos以来, 该协议虽逐渐成为主流一致性协议，但也以难以理解而著名，实现起来比较困难。针对 Raft 难以理解的缺陷， Raft 设计的主要目的之一就是容易理解， Raft 将整个算法过程分解为若干个独立的子过程，并且详细描述了每个子过程如何实现，容易理解和实现。我自己也用 Java 实现了 Raft , 代码在 https://github.com/chicm/CmRaft , 本系列文章的最后我将介绍我的实现。 本文主要参考了 In Search of an Understandable Consensus Algorithm (Extended Version) ，也包含了我自己的理解。 那么什么是一致性算法？ 一致性是分布式容错系统的基本功能，例如在分布式共享文件系统中，通常有多台服务器向客户提供文件服务，当客户通过其中一台服务器A向文件系统存储 了一个文件，如何保证能从服务器B获取刚刚保存的文件？其核心问题在于多台机器就某个值达成一致，一旦某个值达成了一致，客户向整个集群的任何一台机器请 求该值时都会得到同一个值

Paxos算法是什么？ Paxos算法是莱斯利.兰伯特1990年提出的一种基于 消息传递 的、具有高容错性的 一致性算法 。 算法描述 算法角色描述 Paxos算法中有三种角色，分别具有三种不同的行为，一个进程可能同时充当多个角色。 Proposer : 提案的提议者。 Acceptor : 提案的表决者。超过半数的Acceptor同意了提案，则表示提案通过。 Learners :提案的学习者，当提案通过时，需执行提案。 一个集群中可能会存在多个提案者(Proposer)和多个表决者(Acceptor). 算法需保证以下几点： 每个提议者(Proposer)在提出提案时都会首先获得一个全局唯一的、递增的提案号N。 表决者(Acceptor)在同意提案时会将提案编号N保存到本地，承诺后续只会同意编号大于N的提案。 一旦一个题案被选定(超过半数的Acceptor同意了提案)，则其他服务器会主动同步(Learn)该提案。 算法过程描述 Paxos算法的执行过程有两个阶段：准备阶段(prepare)和接受阶段(accept)。 1.准备阶段 提议者(Proposer)准备提交一个提案，这是会获取一个提案编号N，然后将N发送给所有的表决者(Acceptor)，用于判断集群是否支持该编号的提议。 每个表决者(Acceptor)本地都保存了曾经同意过的提案的最大编号N,有上诉请求来时

Paxos 由著名图灵奖获得者Leslie Lamport提出，该算法是分布式一致性算法中的奠基之作，今天初读此文仅将相关学习心得予以记录。 1.Paxos 是什么？主要用来解决什么问题？ Paxos 是一个用于实现可容错的分布式系统的算法，主要用于保证分布式集群中多备份系统之间的操作和数据的一致性。这样集群中的每台机器对外相当于完全一致，从而其互相之间可以互为备份，从而使得系统能够容忍一定数量的机器出问题（宕机、断网、硬盘损坏等等）。 2.Paxos的基本原理是什么？ 介绍paxos的算法之前，首先介绍一个paxos算法中涉及到的几个角色： proposer 提出提案者，在实际应用中可以理解为request的接受者，该角色接收到用户请求，并向集群提出提案要求执行该request。 acceptor 接收者，接收者接收到来自其他的proposer的提案，并按照一定的逻辑决定是否接收当前的提案，也就是是否接收request并准备执行request的角色。 learner 学习者，能够从其他节点获取某个被共识之后的提案。 2.1 paxos解决的问题 假设有n个独立的进程分别能够提出一个值，那么pasos算法用于保证这些进程提出的值的其中之一能够被正确处理。 paxos算法的安全性前提条件为： 只有被提议的值才有可能被选中，也就是说不可能有凭空出现的值出现； 一次只有一个值会被选中；

简述 ：用于解决分布式系统中数据一致性问题 推导过程 ：在Paxos算法中，有三种角色，分别是Proposer（负责提案），Acceptor（负责决策）和Learner（学习最终提案），Paxos的推导是建立在这两个基础之上的： 消息在传输过程中可能会丢失，但不会被篡改。因为分布式系统一般在内网集群中，不容易被篡改，并且通过校验就可以简单判断是否被篡改 每个参与者可能会发生异常，包括数据丢失，关机等 　　在Paxos原始论文（Paxos Made Simple）中，作者是通过不断添加约束条件来推导该算法的 。首先，最简单的方式是选定一个Acceptor，但这种方式容易存在单点故障，因此需要有多个Acceptor，并且规定足够多Acceptor同意的提案才能被选定，后面再讨论足够多是多少。 　　首先，即使只有一个提案被提出，也应该有提案被选定，因此有了第一个约束条件： 　　　 　P1： Acceptor必须同意它收到的第一个提案 　　在P1的基础之上，可能会有这种情况，有n个Proposer，分别向一个Acceptor（总共也n个）提交提案，每个Acceptor都会同意它接受到的第一个提案，此时并不会有一个提案被多数Acceptor批准，如图： 　　 　　或者是只有两个提案被同时提出，但分别被一般Acceptor批准，最终也无法得到最终提案，如图（红色问号代表不可达）： 　　因此

两阶段提交 Two-phase Commit（2PC）：保证一个事务跨越多个节点时保持 ACID 特性； 两类节点：协调者（Coordinator）和参与者（Participants），协调者只有一个，参与者可以有多个。 过程： 准备阶段：协调者询问参与者事务是否执行成功； 提交阶段：如果事务在每个参与者上都执行成功，协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。 需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。 存在的问题 参与者发生故障。解决方案：可以给事务设置一个超时时间，如果某个参与者一直不响应，那么认为事务执行失败。 协调者发生故障。解决方案：将操作日志同步到备用协调者，让备用协调者接替后续工作。 Paxos（Lamport）： 　　分布式系统中的节点通信存在两种模型： 共享内存 （Shared memory）和 消息传递 （Messages passing）。 　　基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即 拜占庭错误 的情况。 　　Paxos算法解决的问题是在一个可能发生上述异常的 分布式系统 中如何就某个值达成一致，保证不论发生以上任何异常

5.Paxos   Paxos算法解决的问题是 一个分布式系统如何就某个值（决议）达成一致 。一个典型的场景就是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。Paxos算法就是一种 基于消息传递模型的一致性算法 。 主要有三类节点： 提议者 （Proposer）:提议一个值； 接受者 （Acceptor）:对每个提议进行投票； 告知者 （Learner）：被告知投票的结果，不参与投票。 执行过程   规定一个提议包含两个字段： [n,v] ，其中 n为序号 （具有唯一性）， v为提议值 。 1.Prepare阶段   下图演示了两个proposer和三个acceptor的系中运行该算法的初始过程， 每个proposer都会向所有的acceptor发送prepare请求 。   当acceptor接受到一个prepare请求，包含的提议为[n1,v1]，并且之前还未接受过prepare请求，那么 发送一个prepare响应 ，设置当前接受到的提议为[n1,v1]，并且 保证以后不会接受序号小于n1的提议 。   如下图，Acceptor X 在收到 [n=2, v=8] 的 Prepare 请求时

文章目录 1.ZooKeeper介绍 1.1文件系统 1.2监听机制 1.3监听工作原理 1.4ZooKeeper典型应用场景 1.4.1命名服务 1.4.2配置管理 1.4.3集群管理 1.4.4分布式锁 1.4.5队列管理 2.ZooKeeper特点 3.Zookeeper原理解析 3.1集群角色描述 3.2Paxos 算法概述（ZAB 协议） 3.2.1ZooKeeper的全新集群选主 3.2.2ZooKeeper的非全新集群选主 3.3数据同步 3.4ZooKeeper工作流程 3.4.4Leader工作流程 3.4.2Follower工作流程 3.4.3Observer工作流程 1.ZooKeeper介绍 ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如 分布式同步，配置管理，集群管理，命名管理，队列管理 。它被设计为易于编程，使用文 件系统目录树作为数据模型。服务端跑在 java 上，提供 java 和 C 的客户端 API。 1.1文件系统 ZooKeeper 的命名空间就是 ZooKeeper 应用的文件系统，它和 linux 的文件系统很像，也是树 状，这样就可以确定每个路径都是唯一的，对于命名空间的操作必须都是绝对路径操作