《zookeeper原理与实践》笔记

第1章 分布式架构

1.1 分布式

分布式特色：分布性、对等性、并发性、缺少全局时钟、故障老是会发生。

分布式问题：通信异常、网络分区（脑裂）、三态、节点故障。

 

1.2 ACID到CAP/BASE

事务：由一系列对系统中数据进行访问与更新的操做所组成的一个程序执行逻辑单元。

ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。

隔离级别：读未提交、读已提交（解决脏读）、可重复读（解决脏读和不可重复读）、串行化（解决脏读，不可重复读和幻读）。

 

分布式事务：是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不一样节点之上。

CAP定理：一个分布式系统不能同时知足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），最多知足两个。

BASE理论：是对CAP中一致性和可用性权衡的结果，来源于大型互联网系统分布式实践的总结。核心思想是能够放弃强一致性，采用适当的方式使系统达到最终一致性。是基本可用（Basically Available）、软状态（Soft state）、最终一致性（Eventually consistent）的缩写。

 

 

第2章 一致性协议

2.1 2PC 二阶段提交协议

二阶段提交将一个事务处理分为投票和执行两个阶段，核心是对事务采用先尝试后提交的处理方式。目前绝大多数关系型数据库采用二阶段提交完成事务处理。

优势：原理简单，实现方便。

缺点：同步阻塞、单点问题、数据不一致（脑裂）、太过保守。

同步阻塞：是两阶段最大最严重的问题，极大影响性能，由于全部参与者都必须等待其余参与者完成，才能进行下一阶段操做。

单点问题：协调者一旦挂了，整个事务处理没法运转，另外收不到请求的参与者会一直处于锁定事务资源的状态中。

数据不一致：一部分收到Commit请求的参与者完成事务提交，而没收到的参与者没法提交，整个分布式系统出现数据不一致。

太过保守：比较脆弱，任何一个节点超时失败都会致使整个事务失败。

 

阶段一：提交事务请求

①协调者发起事务询问：协调者向全部参与者发送事务内容，询问是否能够执行事务提交操做，并等待响应。

②参与者执行事务操做：参与者执行事务操做，并将redo和undo写到事务日志。

③参与者将询问结果响应给协调者：返回Yes或No。

 

阶段二：执行事务提交

A、当所有Yes，则提交事务

①协调者发送提交请求：协调者向全部参与者发出Commit请求。

②参与者执行事务提交：参与者收到Commit请求后，正式执行事务提交操做，完成提交后释放整个事务执行期间占用的系统资源。

③参与者将事务提交结果响应给协调者：返回Ack消息。

④协调者完成事务：协调者接受到全部参与者响应的Ack消息后，完成事务。

 

B、当某一个存在No或超时，则中断事务

①协调者发送回滚请求：协调者向全部参与者发出Rollback请求。

②参与者执行事务回滚：参与者收到Rollback请求后，执行事务回滚操做，完成回滚后释放整个事务执行期间占用的系统资源。

③参与者将事务回滚结果响应给协调者：返回Ack消息。

④协调者中断事务：协调者接受到全部参与者响应的Ack消息后，完成事务中断。

 

2.2 3PC 三阶段提交协议

将二阶段提交协议的第一个阶段一分为二，增长询问阶段，造成了由CanCommit、PreCommit和DoCommit三个阶段组成的事务提交协议。

优势：当可能失败时，由于快速发现失败，下降了参与者的同步阻塞范围，是最大优势。

缺点：多出的询问阶段会增长总体阻塞耗时。

 

2.3 Paxos算法

Paxos算法引入“过半”理念，也就是少数服从多数的原则来避免同步阻塞问题；同时支持分布式节点角色之间的轮换，来避免单点问题和一致性（脑裂）问题。

拜占庭将军问题：从理论上来讲，在分布式计算领域，试图在异步系统和不可靠的通道上来达到一致性状态是不可能的。所以，在一致性研究过程当中，都假设信道是可靠的。

Paxos问题描述：假设有一组能够提出提案的进程集合，那么对于一个一致性算法来讲须要保证如下几点：

①在这些被提出的提案中，只有一个会被选定。

②若是没有提案被提出，就不会有被选定的提案。

③当一个提案被选定后，进程能够获取被选定的提案。

 

Paxos问题难点：有三种参与角色，分别位Proposer、Acceptor、Learner。不一样参与者能够消息通讯，但存在如下问题：

①任何一个参与者都不稳定，随时可能失败或重启。

②消息传输过程当中可能延迟、重复和丢失，但不会被篡改。

 

Chubby：Google开发的粗粒度的分布式锁服务，Paxos算法的工程实现者。其开源参考实现版本为Zookeeper。

 

 

第3章 Zookeeper与Paxos

3.1 初识Zookeeper

ZK是一个开源的分布式协调服务，也是一个分布式数据一致性的解决方案。

ZK设计目标：致力于提供一个高性能、高可用，具备严格的顺序一致性（主要是写操做的严格顺序性）的分布式协调服务。

ZK保证的分布式一致性特性：顺序一致性、原子性、单一视图、可靠性、实时性。

顺序一致性：同一个客户端发起的事务请求，最终将会严格的按照其发起顺序被应用到ZK中。

 

集群角色：Leader（读写，事务请求协调者）、Follower（读、参与Leader选举、参与写操做的“过半写成功”策略）、Observer（读）。

会话：基于客户端与服务端的TCP长链接和会话超时时间实现。

ZNode：简单数据模型是内存中的一颗目录树，树节点叫Znode。分为持久节点和临时节点两大类，节点的顺序属性是由父节点维护的一个自增数字后缀。

 

3.2 ZAB协议

ZAB是ZK实现分布式数据一致性的核心算法。ZAB两种基本模式：崩溃恢复和消息广播。

ZAB协议与Paxos算法的区别：Paxos是一种通用的分布式一致性算法，而ZAB是专门为ZK设计的支持崩溃可恢复的原子消息广播算法。

ZXID：64位全局惟一递增的事务ID，低32位保存单调递增计数器，高32位保存Leader周期epoch的编号。

进程状态：LOOKING（Leader选举阶段）、FOLLOWING（Follower角色）、LEADING（Leader角色）、OBSERVING。

 

3.3 消息广播

ZAB消息广播方式是一个简化的2PC，但去除了中断逻辑（采用过半写成功策略），而且用崩溃恢复来解决协调者（Leader）单点问题。

ZAB事务请求处理流程（相似2PC）：全部事务请求必须由一个全局惟一的Leader服务器来协调处理，Leader负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中全部的Follower服务器并等待其反馈，一旦超过半数的Follower服务器进行正确ACK反馈（投票）后，那么Leader就会再次向全部的Follower服务器分发Commit消息。要求其将前一个的Proposal进行提交。

 

3.4 崩溃恢复

启动条件：Leader崩溃、重启、与过半Follower网络中断时。

退出条件：完成Leader选举，而且新Leader上的全部Proposal已与过半机器完成数据同步，这时新Leader才能接受客户端事务请求。

Leader选举算法：拥有最高编号（ZXID最大）事务Proposal的机器会成为Leader。此算法优势是为了省去新Leader检查Proposal的提交和丢弃工做的这两步操做。

Proposal提交检查：是指ZAB协议须要确保那些已经在Leader服务器上提交的事务最终被全部服务器都提交。

Proposal丢弃检查：是指ZAB协议须要确保丢弃那些只在Leader服务器上被提出的事务。

 

3.5 ZAB与Paxos联系和区别

相同点：都是一个Leader多个Follower，提案提交都采用过半原则，而且都有Leader周期epoch。

区别：Leader选举算法不同，Paxos的新Leader会向全部机器收集老Leader提出的提案，并将他们提交。而ZAB增长发现和同步阶段，拥有最高编号的事务提案会成为Leader。

本质区别：设计目标不同，Paxos用于构建一个分布式的一致性状态机系统，ZAB则用于构建一个例如Zookeeper这样的高可用的分布式数据主备系统。

 

 

第4章 使用Zookeeper

4.1 部署与运行

部署模式：单机、伪集群、集群。

zkCli.sh客户端命令：create、ls、get、set、delete。

zkServer.sh服务器命令：status、start、stop、restart、help。

 

开源客户端：zkClient、Curator。

 

 

第5章 Zookeeper典型应用场景

5.1 数据发布/订阅

即配置中心，ZK采用推拉结合方式：客户端向服务器注册本身要关注的节点，一旦节点数据发生变动，服务器向客户端发送watcher事件通知（push），客户端接收到通知后，须要主动到服务器获取最新的数据（pull）。

 

5.2 命名服务

与JNDI相似，帮助应用系统经过一个资源引用的方式来实现对资源的定位和使用。能够利用目录树结构和ZNode的顺序属性来生成分布式全局惟一ID。

 

5.3 分布式协调/处理

基于ZK的watcher注册与异步通知机制，一般作法是：不一样客户端都对ZK同一个数据节点进行watcher注册，监听数据节点变化。能够实现心跳检测、工做进度汇报、系统调度等。

 

5.4 集群管理

包括集群监控和集群控制两大块。能够实现机器注册、任务分发、状态汇报、动态分配、机器上下线、机器监控等。

 

5.5 Master选举

利用ZK特性实现，即ZK保证客户端没法重复建立一个已经存在的数据节点。作法是：同时多个客户端请求建立同一个节点，那么最终必定只有一个客户端可以建立成功。

 

5.6 分布式锁

排他锁

A、获取锁

①多个客户端同时在/el节点下建立同名临时子节点/el/lock，最终只有一个能建立成功，那么就获取到锁。

②获取锁失败的客户端在该/el节点注册一个子节点变动的watcher监听。

B、释放锁

拥有锁的客户端宕机、用完主动删除。

 

共享锁

A、获取锁

①多个客户端在/sl节点下建立顺序临时子节点/sl/host-读写类型[RW]-序号。

②当写操做时，对比本身序号小的节点注册节点变动watcher监听。

③当读操做时，对比本身序号小的写操做节点注册节点变动watcher监听，当比本身小的都是读操做节点时，则直接获取锁。

B、释放锁

拥有锁的客户端宕机、用完主动删除。

 

5.7 分布式队列FIFO

相似所有为写操做的共享锁模型。

A、获取锁

①多个客户端在/queue节点下建立顺序临时子节点/queue/host-序号。

②对比本身序号小的节点注册节点变动watcher监听。

 

5.8 分布式屏障

①多个客户端在/barrier节点（内容为数字N）下建立临时子节点/barrier/host。

②检查子节点数量是否小于N，知足则对/barrier节点注册一个子节点变动的watcher监听。

 

5.9 ZK在大型分布式系统的应用

Hadoop：ZK主要实现高可用HA功能。如：HDFS的namenode、YARN的resourcemanager。

HBase：HRegionServer的高可用，RootRegion自身的位置管理，Region状态管理等，Replication管理。

Kafka：Broker的注册管理、Topic节点（Topic分区信息与Broker的映射关系）的管理、生产者动态负载均衡（生产者经过对“broker的增减”，“topic的增减”，“topic与broker映射关系变化”等注册watcher监听）、消费者动态负载均衡（同上）。

Dubbo：服务注册中心。

 

 

第6章 Zookeeper技术内幕

6.1 系统模型

ZNode：命名空间树的节点，根节点为“/”，相似Unix文件系统风格。

ZK事务：可以改变ZK服务器状态的操做。包括ZNode建立删除、数据节点内容更新、客户端会话建立与失效等。

ZXID：事务ID，全局自增有序。节点stat中有czxid（建立）、mzxid（最后一次修改）、pzxid（子节点列表最后一次修改，不含子节点内容变动）三种类型。

节点类型：持久、临时、顺序。

临时节点：临时节点生命周期和客户端会话绑定，而不是TCP链接。

节点版本：表示修改次数，刚建立为0次。经过乐观锁和CAS校验机制来保证原子性操做。分为version（节点数据内容）、cversion（子节点列表）、aversion（节点ACL变动）三种类型。

 

watcher机制：包括客户端线程、客户端WatchManager和ZK服务器三部分。实现过程分为三个阶段：客户端注册watcher、服务端处理watcher和客户端回调watcher。

watcher事件：由keeperState和EventType组合实现。keeperState分为4种：SyncConnected、Disconnected、Expired、AuthFailed。而eventType分为5种：None、NodeCreated、NodeDeleted、NodeDataChanged、NodeChildrenChanged。

watcher特性：一次性、客户端串行执行、轻量级。

 

ACL：一条ACL信息的格式为scheme（权限模式）：id（受权对象）：permission（权限）。

scheme权限模式：分为4种，即IP、Digest（用户名：密码）、world、super。

permissionL权限：分为5种，即CREATE、READ、WRITE、DELETE、ADMIN。

 

Jute：zk的序列化组件。

 

6.2 客户端

zk客户端主要有四个核心组件：ZK实例、ClientWatcherManager、HostProvider、ClientCnxn。

zk服务端组件：NIOServerCnxn负责维护每个客户端链接，采用TCP长链接。

 

6.3 会话

session会话的5个状态：connecting、connected、reconnecting、reconnected、close。

会话四个基本属性：sessionID、timeout、ticktime（下次会话超时时间点）、isClosing。

会话采用“分桶策略”管理，为了高效低耗的实现会话的超时检查和清理。

分桶策略：是指将相似的会话放在同一区块中管理，以便ZK对会话进行不一样区块的隔离以及同一区块的统一处理。

 

会话重连：当客户端与服务器网络链接断开后，ZK客户端会自动进行反复的重连，直到最终成功链接上ZK集群中的一台机器。此时若还在会话超时时间内，则重连成功；不然会话失效过时。

会话转移：当网络链接断开后，重连到另一台服务器，则客户端会话将从旧服务器转移到新服务器。

 

6.4 服务器启动

leader选举是单机和集群模式启动最大的不一样点。默认的leader选举算法为FastLeaderElection。根据服务器SID、最新的zxid、当前的服务器epoch来生成一个投票。简单而言，哪一个服务器处理过的数据越新，就越有可能成为leader。zxid相同时，sid最大的成为leader。

 

6.5 Leader选举

ZK服务器的三种角色：Leader、Follower、Observer。

Quorum：过半机器数。计算公式Quorum=（n/2+1）。

Vote：投票的基本元素包含：所推举的服务器sid，所推举服务器的zxid，如（SID，ZXID）。

 

Leader选举概述：

A、服务器启动期间的Leader选举（当首台机器启动时不会选举，此时无leader，只有当第2台启动时才会触发）

①每一个服务器会发出一个投票，初始都投给本身，如（1，0）、（2，0）。

②接收来自各个服务器的投票，并校验投票有效性，如是否为本轮投票，是否来自LOOKING状态的服务器。

③将接收到的别人的N-1个投票和本身的投票PK，选出N个投票中的最大者，若最大者不是本身，则变动投票，经过将收到的最大者投票再次发出，来发起第二轮投票；若最大者是本身则没有第二轮投票。PK规则：先比较ZXID，相同则比较SID。

④统计全部投票，判断是否已经有过半的机器接收到相同的投票信息。

⑤改变服务器状态为Leading或Following。

 

B、服务器运行期间的Leader选举（非Leader机器增减不会选举，仅leader挂了才会）

①每一个Follower服务器变动状态为LOOKING。

②每一个服务器会发出一个投票（SID，ZXID），第一轮投票都投给本身。

③④⑤与上述相同。

 

zk服务器状态：分别为LOOKING、FOLLOWING、LEADING和OBSERVING。

 

FastLeaderElection选举算法核心概念：

外部投票：特指其余服务器发来的投票。

内部投票：服务器自身当前的投票。

选举轮次：ZK服务器Leader选举的轮次，即logicalClock。

PK：将内部投票和外部投票进行一个对比来肯定是否须要变动内部投票。

sendQueue：选票发送队列。

recvQueue：选票接收队列。

recvSet：选票归档集合。不管是否发生了选票变动，都会将刚刚收到的那份外部选票放入选票集合recvSet中进行归档。完成归档后，开始统计选票。

 

6.6 请求处理

ZK中每个事务请求都须要集群中过半机器投票承认后，才能被真正应用到ZK内存数据库中去。

事务处理相关概念：生成并广播提议Proposal、收集ACK消息反馈、广播Commit。

 

6.7 数据与存储

ZK数据存储分为内存和硬盘两部分。内存数据模型是一棵树DataTree。

ZKDatabase：ZK内存数据库，负责管理ZK全部会话，DataTree存储和事务日志。会定时向磁盘dump快照数据，同时在zk启动时，会经过磁盘上的事务日志和快照数据文件恢复成一个完整的内存数据库。

dataDir：快照数据目录。名为“snapshot.ZXID”二进制文件。

dataLogDir：事务日志目录。名为“log.ZXID”的二进制文件。

 

 

第7章 Zookeeper运维

7.1 配置详解

tickTime：配置zk中最小时间单元的长度，其余时间都是以其倍数来表示，单位毫秒。

initTime：配置Leader服务器等待Follower启动，并完成数据同步的时间。集群庞大时须要加大。

syncTime：配置Leader与Follower之间进行心跳检测的最大延时时间。

snapCount：配置两次数据快照之间事务操做次数。

 

7.2 四字命令

经过telnet客户端登陆zk对外服务的2181端口，而后输入四字命令。

 

7.3 集群组成

zk集群只能部署为奇数个是错误的认识。任意台机器都能部署且可以正常运行。若要进一步知足集群可用，则需知足“过半存活便可用”的特性。

过半存活便可用：一个zk集群要对外提供一个“可用”的服务，那么集群中必需要有过半的机器正常工做而且彼此之间可以正常通讯。

基于该特性，若想搭建容许F台down掉的集群，则服务器数量应该为2*F+1台。例如：6台和5台相比，都是只容许2台down掉，在容灾能力上没有任何优点，只会浪费资源，所以官方建议部署奇数个。