微信读书：从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服务器都能部署且可能失常运行。