zab

参考： 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算法浅析 中主要介绍了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解决了因果顺序问题