共计 2997 个字符，预计需要花费 8 分钟才能阅读完成。
微信读书：从 Paxos 到 Zookeeper：分布式一致性原理与实际（浏览摘录）
浏览地址
CAP 实践
CAP 实践通知咱们，一个分布式系统不可能同时满足一致性 (C：Consistency)、可用性(A：Availability) 和分区容错性 (P：Partition tolerance) 这三个根本需要，最多只能同时满足其中的两项。
BASE 实践
BASE 是 Basically Available（根本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写，是由来自 eBay 的架构师 Dan Pritchett 在其文章 BASE：An Acid Alternative[插图]中第一次明确提出。
2PC 与 3PC
2PC
2PC，是 Two-Phase Commit 的缩写，即二阶段提交，是计算机网络尤其是在数据库畛域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中可能放弃原子性和一致性而设计的一种算法。通常，二阶段提交协定也被认为是一种一致性协定，用来保障分布式系统数据的一致性。目前，绝大部分的关系型数据库都是采纳二阶段提交协定来实现分布式事务处理的，利用该协定可能十分不便地实现所有分布式事务参与者的协调，对立决定事务的提交或回滚，从而可能无效地保障分布式数据一致性，因而二阶段提交协定被宽泛地利用在许多分布式系统中。
3PC
3PC，是 Three-Phase Commit 的缩写，即三阶段提交，是 2PC 的改进版，其将二阶段提交协定的“提交事务申请”过程一分为二，造成了由 CanCommit、PreCommit 和 do Commit 三个阶段组成的事务处理协定。
Paxos 算法
拜占廷将军问题
拜占庭帝国有许多支军队，不同军队的将军之间必须制订一个对立的行动计划，从而做出防御或者撤退的决定，同时，各个将军在天文上都是被分隔开来的，只能依附军队的通讯员来进行通信。然而，在所有的通讯员中可能会存在叛徒，这些叛徒能够任意篡改音讯，从而达到坑骗将军的目标。
这就是驰名的“拜占廷将军问题”。从实践上来说，在分布式计算畛域，试图在异步零碎和不牢靠的通道上来达到一致性状态是不可能的，因而在对一致性的钻研过程中，都往往假如信道是牢靠的。而事实上，大多数零碎都是部署在同一个局域网中的，因而音讯被篡改的状况十分常见；另一方面，因为硬件和网络起因而造成的音讯不残缺问题，只需一套简略的校验算法即可防止——因而，在理论工程实际中，能够假如不存在拜占庭问题，也即假如所有音讯都是残缺的，没有被篡改的。那么，在这种状况下须要什么样的算法来保障一致性呢？
ZooKeeper 的 ZAB 协定
ZooKeeper 并没有齐全采纳 Paxos 算法，而是应用了一种称为 ZooKeeper Atomic Broadcast（ZAB，ZooKeeper 原子音讯播送协定）的协定作为其数据一致性的外围算法。
ZAB 协定的外围是定义了对于那些会扭转 ZooKeeper 服务器数据状态的事务申请的解决形式，即：
所有事务申请必须由一个全局惟一的服务器来协调解决，这样的服务器被称为 Leader 服务器，而余下的其余服务器则成为 Follower 服务器。Leader 服务器负责将一个客户端事务申请转换成一个事务 Proposal（提议），并将该 Proposal 分发给集群中所有的 Follower 服务器。之后 Leader 服务器须要期待所有 Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正确的反馈后，那么 Leader 就会再次向所有的 Follower 服务器散发 Commit 音讯，要求其将前一个 Proposal 进行提交。
ZooKeeper 的 Watcher 的个性
- 一次性
- 客户端串行执行
- 轻量
ZooKeeper 的 ACL 机制
ZooKeeper 的 ACL 权限管制和 Unix/Linux 操作系统中的 ACL 有一些区别，读者能够从三个方面来了解 ACL 机制，别离是：权限模式 (Scheme)、受权对象(ID) 和权限(Permission)，通常应用“scheme：id：permission”来标识一个无效的 ACL 信息。
ZooKeeper 的会话激活
为了放弃客户端会话的有效性，在 ZooKeeper 的运行过程中，客户端会在会话超时工夫过期范畴外向服务端发送 PING 申请来放弃会话的有效性，咱们俗称“心跳检测”。
单机版 ZooKeeper 服务器启动流程
集群版 ZooKeeper 服务器启动流程
Leader
在接管到来自其余服务器的投票后，针对每一个投票，服务器都须要将他人的投票和本人的投票进行 PK，PK 的规定如下。
- 优先查看 ZXID。ZXID 比拟大的服务器优先作为 Leader。
- 如果 ZXID 雷同的话，那么就比拟 myid。myid 比拟大的服务器作为 Leader 服务器。
一旦 Leader 所在的机器挂了，那么整个集群将临时无奈对外服务，而是进入新一轮的 Leader 选举。
简略地说，通常哪台服务器上的数据越新，那么越有可能成为 Leader，起因很简略，数据越新，那么它的 ZXID 也就越大，也就越可能保证数据的复原。当然，如果集群中有几个服务器具备雷同的 ZXID，那么 SID 较大的那台服务器成为 Leader。
Quorum：过半机器数
这是整个 Leader 选举算法中最重要的一个术语，咱们能够把这个术语了解为是一个量词，指的是 ZooKeeper 集群中过半的机器数，如果集群中总的机器数是 n 的话，那么能够通过上面这个公式来计算 quorum 的值：
例如，如果集群机器总数是 3，那么 quorum 就是 2。
申请解决链
应用责任链模式来解决每一个客户端申请是 ZooKeeper 的一大特色。
Foller
从角色名字上能够看出，Follower 服务器是 ZooKeeper 集群状态的跟随者，其次要工作有以下三个。
- 解决客户端非事务申请，转发事务申请给 Leader 服务器。
- 参加事务申请 Proposal 的投票。
- 参加 Leader 选举投票。
Observer
Observer 是 ZooKeeper 自 3.3.0 版本开始引入的一个全新的服务器角色。从字面意思看，该服务器充当了一个观察者的角色——其察看 ZooKeeper 集群的最新状态变动并将这些状态变更同步过去。Observer 服务器在工作原理上和 Follower 根本是统一的，对于非事务申请，都能够进行独立的解决，而对于事务申请，则会转发给 Leader 服务器进行解决。和 Follower 惟一的区别在于，Observer 不参加任何模式的投票，包含事务申请 Proposal 的投票和 Leader 选举投票。简略地讲，Observer 服务器只提供非事务服务，通常用于在不影响集群事务处理能力的前提下晋升集群的非事务处理能力。
ZooKeeper 的音讯类型
ZooKeeper 的音讯类型大体上能够分为四类，别离是：数据同步型、服务器初始化型、申请解决型和会话管理型。
四字命令
高可用集群
要搭建一个高可用的 ZooKeeper 集群，咱们首先须要确定好集群的规模。对于 ZooKeeper 集群的服务器组成，置信很多对 ZooKeeper 理解然而了解不深刻的读者，都存在或已经存在过这样一个谬误的意识：为了使得 ZooKeeper 集群可能顺利地选举出 Leader，必须将 ZooKeeper 集群的服务器数部署成奇数。这里咱们须要廓清的一点是：任意台 ZooKeeper 服务器都能部署且可能失常运行。
