paxos

前言 在上一篇文章 Paxos算法浅析 中主要介绍了Paxos一致性算法应用的场景，以及对协议本身的介绍；Google Chubby是一个分布式锁服务，其底层一致性实现就是以Paxos算法为基础的；但这篇文件并不是介绍Chubby，而是介绍了一个和Chubby拥有类似功能的开放源码的分布式协调服务Zookeeper，以及Zookeeper数据一致性的核心算法ZAB。 Zookeeper简介 Zookeeper是一个分布式数据一致性的解决方案，分布式应用可以基于它实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。Zookeeper致力于提供一个高性能、高可用、且具有严格的顺序访问控制能力的分布式协调系统。 考虑到Zookeeper主要操作数据的状态，为了保证状态的一致性，Zookeeper提出了两个安全属性: 1.全序（Total order）：如果消息a在消息b之前发送，则所有Server应该看到相同的结果 2.因果顺序（Causal order）：如果消息a在消息b之前发生（a导致了b），并被一起发送，则a始终在b之前被执行。 为了保证上述两个安全属性，Zookeeper使用了 TCP协议和Leader ： 通过使用TCP协议保证了消息的全序特性（先发先到）， 通过Leader解决了因果顺序问题

无论是云计算、大数据还是互联网公司的各种应用，其后台基础设施的主要目标都是构建低成本、高性能、可扩展、易用的分布式存储系统。 大规模分布式存储系统的定义如下：分布式存储系统是大量普通PC服务器通过Internet互联，对外作为一个整体提供存储服务。 几个特点： （1）可扩展：分布式存储系统可以扩展到几百台甚至上千台的集群规模，而且，随着集群规模的增长，系统整体性能表现为线性增长 （2）低成本：自动容错、自动负载均衡机制使其可以构建在普通PC机之上。另外，线性扩展能力也使得增加、减少机器非常方便，可以实现自动运维。 （3）高性能：针对整个集群还是单台服务器，都要求分布式存储系统具备高性能。 （4）易用：分布式存储喜提需要能够提供易用的对外接口，另外，也要求具备完善的监控、运维工具。 分布式存储数据需求比较复杂，大体可以分为三类： （1）非结构化数据 （2）结构化数据 （3）半结构化数据 不同的分布式存储系统适合处理不同类型的数据，将分布式存储系统分为四类： （1）分布式文件系统：互联网应用需要存储大量的图片，视频等非结构化数据对象，这类数据以对象的形式组织，对象之间没有关联，这样的数据一般称为Blob数据（Binary Large Object二进制大对象） 分布式文件系统存储三种类型的数据：Blob对象，定长块，大文件 （2）分布式键值系统：存储关系检点的半结构化数据

After reading paxos and raft paper, I have following confusion: paxos paper only describe consensus on single log entry, which is equivalent the leader election part of the raft algorithm. What's the advantage of paxos's approach over the simple random timeout approach in raft's leader election? It is a common misconception that the original Paxos papers don't use a stable leader. In Paxos Made Simple on page 6 in the section entitled “The Implementation” Lamport wrote: The algorithm chooses a leader, which plays the roles of the distinguished proposer and the distinguished learner. This is

在实际开发中，我们的大型项目都需要设计分布式架构，同时对高并发的场景进行管理，而在高并发环境中，我们通过使用redis集群来管理和控制该场景，同时，我们需要保证数据库与缓存的双写一致性，同时因为在常见的高并发场景中，我们对于微服务的控制并不能很好的应对该场景，如spring cloud和docker的结合并不能很好的解决该问题，因此我们需要相应的算法和协议来维持分布式架构的一致性。 如图所示，我们在分布式架构中，通常对于服务器的管理，我们通过观察是否存在特洛伊问题来决定使用哪种方法来解决分布式架构一致性。 在非特洛伊问题中，我们使用paxos和raft协议来维持分布式架构一致性，例如，在使用spring+spring MVC+Mybatis的开发中，我们经常使用@RequestBody 注解来返回一个json格式的网络状态，在常用的消息队列中，例如RabbitMQ,我们使用消息中间件的特性来进行程序的解耦削峰异步，通过消息中间件的作用，我们使传统RPC的方式变为了分布式，从而解决了系统的耦合性，但是对于大型业务场景，消息中间件会产生消息丢失，消息转发失败等系统问题，所以我们在设计架构的时候，通过会使用消息队列锁定算法来维持消息的稳定性，但对于高并发场景一味的使用synchronized或者乐观锁是不现实的，所以我们会使用分布式锁，自旋锁等高级锁来保持高并发场景的读写一致性。

前言 在文章 2PC/3PC到底是啥 中介绍了2PC这种一致性协议，从文中了解到2PC更多的被用在了状态一致性上(分布式事务)，在数据一致性中很少被使用；而Paxos正是在数据一致性中被广泛使用，在过去十年里，Paxos基本成为了分布式领域内一致性协议的代名词。Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：“所有一致性协议本质上要么是Paxos要么是其变体”。Paxos的提出者LeslieLamport也因其对分布式系统的杰出理论贡献获得了2013年图灵奖。 在介绍Paxos之前，先介绍一下数据一致性到底被用在什么场景中，下面以副本状态机来表述 副本状态机 在分布式环境下，一致性协议的应用场景一般会采用副本状态机来表达，这是对各种不同应用场景的一种抽象化表述。 一种典型的实现副本状态机的机制是采用Log副本的方式，如下图(来源网上)： 集群中多台服务器各自保存一份Log副本及内部状态机，Log内顺序记载客户端发来的操作指令，服务器依次执行Log内的指令并将其体现到内部状态机上，如果保证每台机器内的Log副本内容完全一致，那么对应的状态机也可以保证整体状态一致。 一致性协议的作用就是保证各个Log副本数据的一致性，上图中的一致性模块就是用来保证一致性的。 再来看一个更具体的例子：在一个分布式数据库系统中，如果各节点的初始状态一致

http://thesecretlivesofdata.com/raft/ CONSENSUS: BRIDGING THEORY AND PRACTICE https://ramcloud.stanford.edu/~ongaro/thesis.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf https://understandingpaxos.wordpress.com/ http://www.julianbrowne.com/article/brewers-cap-theorem 使用Paxos前的八大问题 https://zhuanlan.zhihu.com/p/23811020 动画 http://thesecretlivesofdata.com/raft/ 如何浅显易懂地解说 Paxos 的算法？ https://www.zhihu.com/question/19787937 https://raft.github.io/ https://web.stanford.edu/~ouster/cgi-bin/papers/raft-atc14 https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia

一致性算法—Paxos、Raft、ZAB 2019年04月21日 20:35:09 bulingma 阅读数 64 更多 分类专栏： 分布式概念 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/bulingma/article/details/89438851 写在前面 1、分布式系统对fault tolerence的一般解决方案是state machine replication（状态机复制）。 2、分布式一致性算法的一种更准确的说法应该是：state machine replication的共识（consensus）算法。 3、pasox其实是一个共识算法。系统的最终一致性，不仅需要达成共识，还会取决于client的行为。 4、分布式系统中有多个节点就会存在节点间通信的问题，存在着两种节点通讯模型：共享内存（Shared memory）、消息传递（Messages passing），以下谈到的算法都是基于消息传递的通讯模型的。它的假设前提是，在分布式系统中进程之间的通信会出现丢失、延迟、重复等现象，但不会出现传错的现象。以下的算法就是为了保证在这样的系统中进程间基于消息传递就某个值达成一致。 一、一致性概述 当前工业实际应用中的一致性模型分类 1.1、弱一致性

参考： Zookeeper的一致性协议：Zab Chubby&Zookeeper原理及在分布式环境中的应用 Paxos vs. Viewstamped Replication vs. Zab Zab vs. Paxos Zab: High-performance broadcast for primary-backup systems Chubby：面向松散耦合的分布式系统的锁服务 Chubby 和Zookeeper 的理解 zookeeper 使用Zab(zookeeper atom broadcast). Zab集群机器越多，写性能会有所降低、读性能得到水平扩展。从Follower直接读取数据，虽不保证最新但最终会读到最新的，为其应用领域配置管理上读>>写而设计。 具体下面描述更加清楚： Zab is a different protocol than Paxos, although it shares with it some key aspects, as for example: A leader proposes values to the followers Leaders wait for acknowledgements from a quorum of followers before considering a proposal committed

这三个都是分布式一致性协议，ZAB基于Paxos修改后用于ZOOKEEPER协议，RAFT协议出现在ZAB协议之后，与ZAB差不多，也有很大区别。 1. Paxos 分布式节点分为3种角色， Proposer， Acceptor， Learner Proposer:提出议案[Mn, Vn] Accptor:决定最终议案 Learner:不参与议案的提出与决定，学习最后的议案 Proposer: 　　1. prepare阶段：提出议案编号M， 向Acceptor集合发送 　　2. 如果收到来自半数以上的Acceptor响应，向Acctoptor发送Accept请求 Acceptor: 　　1. Prepare：响应proposer prepare请求 　　2. Accepte: 响应Accept请求 2. ZAB协议 　　节点分为3种角色1, Follower, Leader, Observer 　　1. 选出leader 　　2. 客户端提出的事物都转给Leader处理 　　类似二阶段协议 　　1. Leader发送Propose给Fowller 　　2. 收到半数以上Ack，发送Commit给Follwer 　　3. Observer不参与Leader选举，同步数据，数据副本。客户端可以读取Observer数据，提高Zookeeper集群工作效率 来源： https://www