《从Paxos到ZooKeeper 分布式一致性原理与实践》读书笔记

1、分布式架构

一、分布式特色

• 分布性
• 对等性。分布式系统中的全部计算机节点都是对等的
• 并发性。多个节点并发的操做一些共享的资源
• 缺少全局时钟。节点之间经过消息传递进行通讯和协调，由于缺少全局时钟，很难定义两个事件谁先谁后
• 故障老是会发生。系统设计时，须要考虑到任何异常状况

二、分布式环境的各类问题

• 通讯异常。分布式系统中的某些节点之间没法正常通讯
• 网络分区。这有部分节点能够正常通讯，有些没法正常通讯。这种现象称为网络分区，也称为“脑裂”
• 三态。节点之间的一次通讯存在三种状态：成功、失败、超时
• 节点故障。节点机器宕机、失去回应

三、传统事务的ACID理论。

• 原子性（Atomicity）。事务内的全部操做要么所有成功，要么所有失败
• 一致性（Consistency）。事务的执行不能破坏数据库的一致性。若是事务执行一半停了，一部分的修改写入的数据库。这时候，数据库就处于一种不正确的状态，或者说不一致的状态
• 隔离性（Isolation）。多个事务并发执行，彼此不会受影响。事务的隔离级别：读未提交（可能发生脏读、重复读、幻象读）、读已提交（肯能发生重复读、幻象读）、可重复读（可能发生幻象读）、串行化。隔离级别越高，对并发的性能影响越大，越能保证数据库的一致性。
• 持久性（Durablility）。一旦事务成功提交，它对于数据的修改就被永久保存下来

四、分布式事务的CAP理论和BASE理论

• CAP理论。一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），在分布式系统中，最多只能知足其中的两项。
• BASE理论。基本可用（Basically Available）、软状态（Soft state）、最终一致性（Eventually consistent）。基本可用指系统出现故障时，容许损失部分可用性，包括响应时间的损失和功能上的系统降级；软状态指容许节点间的通信出现中间状态；最终一致指系统的全部的数据副本，在必定时间的同步后，最终可以达到一致的状态

2、一致性协议

一、2PC。二阶段提交协议

阶段一，执行事务

• 事务询问。协调者向全部参与者发送事务内容，等待参与者回应
• 执行事务。参与者执行事务，记录Undo和Redo日志
• 反馈事务询问响应，参与者返回给协调者Yes或No响应。所有返回Yes，进入提交事务阶段；存在No返回或者超时，进入中断事务阶段

阶段二，提交事务

• 发送事务提交请求
• 各个参与者提交事务
• 参与者反馈事务提交结果
• 若是参与者所有返回Yes，完成事务；存在返回No，进入中断事务阶段

中断事务阶段

• 发送回滚请求
• 事务回滚
• 反馈事务回滚结果
• 完成中断事务

2PC的缺点

• 同步阻塞。各个参与者在等待其余参与者响应的同时，没法进行任何操做，处于阻塞状态
• 单点问题。过分依赖协调者，一旦协调者出现问题，系统将没法正常运转
• 数据不一致。同上一条，一旦协调者出现问题，就可能出现各个参与者数据不一致的问题
• 太过保守。一旦参与者出现故障，协调者只能经过本身的超时机制发现。

二、3PC。三阶段提交协议

 阶段一，CanCommit，事务询问

• 事务询问，询问各个参与者可否完成事务
• 各个参与者返回响应，所有返回Yes，进入PreCommit阶段

阶段二，PreCommit，事务预提交

• 发送预提交请求
• 事务预提交。参与者执行事务操做，记录Undo和Redo日志
• 参与者返回响应。所有返回Yes，继续三阶段；返回No，进入中断事务阶段

阶段三，DoCommit，真正的事务提交

• 发送提交请求
• 参与者正式执行事务提交操做
• 返回协调者事务执行结果
• 协调者完成事务。若是存在返回No或者返回超时，进入中断事务阶段

中断事务阶段

• 发送回滚请求
• 事务回滚
• 反馈事务回滚结果
• 完成中断事务

3PC优缺点

• 优势是下降了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
• 缺点是，仍是避免不了出现数据不一致的状况

三、Paxos算法

拜占庭将军问题，拜占庭帝国的不一样军队处于不一样的地理问题，他们之间只能经过通信员进行通信，可是通信员是不可靠的，可能篡改消息

因为加密算法和校验算法的出现，全部实际的分布式系统之间的通信，不存在数据被篡改的可能。

4、ZooKeeper和ZAB协议介绍

一、初识ZeeKeeper

ZooKeeper能够作什么

能够基于它实现负载均衡、集群管理、Master选举、分布式队列、分布式锁、命名服务、数据发布/订阅等功能

Zookeeper能保证的分布式一致性特性

• 顺序一致性。同一个客户端发起的请求，会严格按照发起顺序执行
• 原子性。对于一个事务请求，集群中的全部机器的执行状况是一致的
• 可靠性。一旦服务端成功的应用了一个事务，并完成了对客户端的响应。服务端的状态会一直保存下来
• 实时性。保证在一段时间内的实时性
• 单一视图。不管客户端链接的是哪个服务器，看到的服务端的数据模型都是一致的

Zookeeper的设计目标

• 简单的数据模型。Zookeeper将去数据存储在内存中，采用树形结构存储，树由ZNode节点构成
• 能够构建集群。只有集群中超过一半机器可以正常运做，整个集群就能够正常对外提供服务。
• 顺序访问。每一个来自客户端的请求，都会分配一个全局惟一的递增编号
• 高性能。全量数据存储在内存中，3台3.4.3的Zookeeper集群，100%读请求场景的压测结果是12-13W的QPS

Zookeeper的基本概念

• 集群角色。存在Leader、Follower、Observer三种角色。Leader服务器提供读和写服务，Follower和Observer提供读服务，可是Observer不参与选举过程，也不参与写操做的“过半写”策略，所以，Observer能够在不影响写性能的状况下提升读性能
• 客户端会话。客户端经过TCP长链接和服务端相连，第一次创建链接就表明客户单会话开始了。客户端可以经过心跳检测与服务器保持有效的会话。Session的SessionTimeout值用来设置会话的超时时间，链接断开后，只要在超时时间以内从新链接上了集群中的任何一台服务器，那么以前建立的会话仍然有效
• 节点。一方面只集群中的每一台机器，称为机器节点；另外一方面指数据模型中的数据单元，称为数据节点Znode。Znode又分为持久节点和临时节点，临时节点的生命周期和会话绑定，一旦客户端会话失效，那么这个客户端建立的全部临时节点都会被移除。
• 版本。每一个Znode，会维护一个叫作Stat的数据结构，记录了Znode的三个版本：version（当期版本）、cversion（当前Znode子节点的版本）、aversion（当前Znode的ACL版本）。
• Watcher。事件监听器，容许用户在一些节点上注册一些watcher。特性事件触发的时候，服务器会将事件通知到感兴趣的客户端上去。
• ACL。权限控制策略（Access Control Lists）。定义了五种权限：Create（建立子节点）、Delete（删除子节点）、read（读取节点数据和子节点列表）、write（更新节点数据）、admin（设置节点ACL的权限）

二、ZAB协议（Zookeeper Atomic Broadcast，原子消息广播协议）

全部事务请求都由Leader服务器来处理分发，若是集群中的其余服务器收到了来自客户端的请求，这些非Leader服务器会首先将这个事务请求转发给Leader服务器，Leader负责将请求封装成Proposal（提议）分发给集群中全部Follower，一旦收到超过半数的正确反馈，Leader就会再次向全部的Follower分发Commit消息，要求他们将前一个Prosocal提交

两种基本模式：崩溃恢复模式和消息广播模式

• 消息广播模式。相似于二阶段提交，去掉了中断逻辑，当Leader服务器收到了超过半数的Follower的ACK响应后，就会广播一个Commit消息给全部的Follower进行事务提交。
• 崩溃恢复。一旦Leader服务器出现崩溃，或者因为网络缘由失去了一半Follower服务器的联系，就会进入崩溃恢复模式。
• 崩溃恢复须要确保已经被Leader提交的Proposal也能被全部Follower提交
• 确保丢弃只在Leader服务器上提出的事务。（此处的提出指的是二阶段第一阶段）。从新选举出来的Leader拥有集群中全部服务器最高编号的事务Proposal
• 正常状况的数据同步：Leader服务器为每个Follower服务器准备一个队列，将那些没有被Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower，等待全部事务都同步到了Follower并成功应用到了Follower的本地数据库中后，Leader服务器就将该Follower服务器加入到真正的可用列表中
• 事务编号ZXID，是一个64位的数字。前32位存储Leader届数，后32位记录本届Leader处理的消息数。

三、深刻ZAB协议

运行分析，每个进程都有可能处于如下三种状态之一

• LOOKING：leader选举阶段
• FOLLOWING：Follower服务器和Leader服务器保持同步状态
• LEADING：Leader服务器做为主进程领导状态

5、使用Zookeeper

一、服务端部署与运行

• 初次使用，须要把/conf目录下的zoo_sample.cfg文件重命名为zoo.cfg。配置以下：
• server.1=IP1:2888:3888，每一行这样的配置表明一个集群中的一个机器，server.1中的1表明ServerID，同时在每台机器上须要在数据目录（dataDir指定的目录）下建立一个myid文件，文件内容就是ServerID，id范围是1~255
• 集群中每一个机器的zoo.cfg文件都应该是相同的，最好使用git或者svn把配置管理起来
• 启动服务。/bin/zhServer.sh  start
• 中止服务。/bin/zkServer.sh stop

二、客户端脚本

• 启动。/bin/zkCli.sh  -server ip:port（不加server参数，默认链接本机）
• 建立节点。create 【-s】【-e】path data acl。acl用来进行权限控制
• 读取节点下子节点。ls path。例如：ls /  查看根节点下的全部子节点
• 读取节点数据。get path
• 更新节点数据。set path data 【version】
• 删除节点。delete path 【version】。没法删除一个包含子节点的节点

三、开源客户端Curator的使用

直接看个人github代码：https://github.com/leon66666/zookeeper-client

6、Zookeeper的典型应用场景

一、典型应用场景及实现

（1）数据发布和订阅

分为推（push）模式和拉（pull）模式，push模式服务端主动把数据更新推送给全部订阅的客户端，而拉模式是由客户端定时轮询拉取的方式来获取最新数据

应用场景：分布式系通通一配置，例如机器列表信息、运行时的开关配置、数据库配置信息等，这些全局配置交给Zookeeper统一管理

这些配置具备如下特色：

• 数据量一般比较小
• 数据内容在运行时动态变化
• 集群中各机器共享，配置一致

（2）负载均衡

DDNS，动态DNS解析。局域网内部通常采用host绑定的方式来进行ip和域名的映射。一旦机器规模变大，这种作法就会至关的不方便。

经过Zookeeper实现，每一个应用均可以建立一个属于本身的数据节点做为域名配置的根节点，在这个节点上，每一个应用均可以将本身的域名配置上去。经过注册Watcher实现域名变动通知功能。

上图为总体的DDNS系统架构。

• Register集群负责域名的动态注册。每一个服务者启动的时候，都会把本身的域名信息注册到Register集群中去。
• Dispatcher集群负责域名的解析。服务消费者在使用域名的时候，会向Dispatcher集群发出请求，获取相应的IP：PORT信息。
• Scanner集群负责检测及维护服务状态（探测服务可用性、屏蔽异常服务节点）。（一种是心跳检测，须要客户端和服务端创建起tcp长链接。另外一种是服务端主动进行状态汇报，一旦超过5秒没有收到汇报，就认为该IP地址不可用，进行域名清理）
• SDK，提供各个语言的系统接入
• Monitor负责收集集群信息以及对DDNS自身的监控
• Controller是一个后台管理，负责受权管理、流量控制、服务配置和手动屏蔽服务等功能。

（3）命名服务

即分布式环境下，生成全局惟一ID的方法。你们通常会联想到UUID，是通用惟一识别码的简称。主流ORM框架HIbernate就有对UUID的直接支持。

可是，UUID有以下缺点：

• 长度过长，须要更多的存储空间
• 含义不明，根据字符串开发人员从字面上根本看不出他的含义

利用Zookeeper来实现这类全局惟一ID的生成。当客户端建立一个顺序子节点的时候，zookeeper会自动之后缀的形式在其子节点上添加一个序号，利用了zookeeper顺序节点的特性

（4）分布式协调/通知

Zookeeper实现分布式协调通知，一般的作法是不一样的客户端都对Zookeeper上同一个数据节点进行Watcher注册。监听节点数据的变化。

（5）通用的分布式系统机器间通讯方法

分布西系统机器间通讯包括：心跳检测、工做进度报告、系统调度

• 心跳检测。不一样机器之间须要检测到彼此是否正常运行。传统方法经过机器之间可否互相ping通来判断；更复杂的经过机器之间创建起Tcp长链接，经过tcp固有的心跳检测机制来实现上层机器的心跳检测；基于Zookeeper的临时节点特性也能够实现心跳检测，不一样的机器在指定节点下建立临时节点，不一样机器能够经过判断临时节点是否存在来判断客户端机器是否存活。减小了系统耦合
• 工做进度报告。每一个客户端建立临时子节点，各个任务机器会实时的将本身的执行进度存储到对应的子节点上，也能够判断子节点是否存在判断机器是否存活
• 系统调度。一个分布式系统由控制台和客户端组成。后台管理人员在控制台作一些操做（实际上就是修改Zookeeper上某些节点的数据），Zookeeper以事件通知的形式发送给对应的订阅客户端

（6）集群管理

集群管理需求点

• 知道集群中工做的机器数量
• 对集群中每台机器的运行状态进行收集
• 对集群中的机器进行上下线操做

传统的基于agent的管理方式，集群中每台机器部署一个agent，负责本机器的监控和向中心系统汇报

• 大规模升级困难
• 统一的agent没法知足多样的需求。没法深刻应用内部，对一些业务状态进行监控
• 编程语言多样性。不一样机器须要提供不一样语言的agent

利用zookeeper监控集群

• 客户端能够对zookeeper节点进行监听，节点变动会受到通知
• 在zookeeper上建立临时节点，一旦会话失效，改临时节点会被自动删除
• 监控系统在/clusterServers节点上注册一个Watcher监听，添加机器会在监听节点下建立临时子节点。

zookeeper监控应用：分布式日志收集系统

• 注册收集器机器。以/logs/controller做为收集器的根节点，每一个收集器启动的时候都会在收集器节点下建立本身的节点
• 任务分发。收集系统把日志源机器按照必定策略分配给注册的收集器机器，将机器列表写入到对应的收集器节点上
• 状态汇报。收集器节点下面建立状态子节点，每一个注册的收集器机器定时向该节点写入本身的状态信息和日志收集进度信息（能够看作是一种心跳检测），根据更新时间来判断是否存活
• 动态分配。检测到收集器的减小或者增长以后，须要进行从新分配。一般有两种作法：全局分配（影响面大）；局部动态分配（低负载优先分配）
• 节点类型。收集器节点，需使用持久节点，须要保存该节点上的日志源机器列表
• 收集器节点监听。放弃监听设置，采用按期轮询，节省网卡流量，可是具备一些延时，考虑到日志收集需求，延时是能够接受的

 （7）Master选举

在集群的全部机器中选举出一台机器做为master

• 能够经过数据库的主键惟一特性来实现。可是当选举出的master挂了以后，数据库没法通知咱们这个事件
• 利用zookeeper的强一致性，客户端没法建立一个已经存在的节点。其余没有成功建立这个节点的客户端会在这个节点上注册一个子节点变动的watcher，一旦发现当前的master挂了，其他客户端会从新进行选举

（8）分布式锁

最多见的是用数据库实现。例如行锁，表锁，事务处理，乐观锁等等。可是每每分布式系统的性能瓶颈都集中在数据库的操做上。

• 排它锁。选择一个节点做为锁节点，客户端加锁的时候会在锁节点先建立临时子节点，利用zookeeper特性，只有一个客户端可以建立成功，其他客户端注册锁节点的子节点变动的Watcher监听，在持有锁的客户端主动删除临时节点或者因为宕机致使会话超时致使临时节点被移除，都表示锁被释放了。其余监听的客户端会再次发起分布式锁获取
• 共享锁。在锁节点下建立临时顺序节点。读节点为R+序号，写节点为W+序号。建立完节点后，获取全部子节点，对锁节点注册子节点变动的watcher监听，肯定本身的序号在全部子节点中的位置。对于读请求，没有比本身序号小的写节点，就表示得到了共享锁，执行读取逻辑。对于写请求，若是本身不是序号最小的子节点，就须要进入等待。接收到watcher通知后，重复获取锁。
• 共享锁羊群效应。大量的watcher通知和子节点列表获取，两个操做重复运行。集群规模比较大的状况下，会对zookeeper服务器形成巨大的性能影响和网络冲击
• 改进后的共享锁。读请求，监听比本身小的写节点。写请求，监听比本身小的最后一个节点。
• 具体选用哪一种实现的共享锁，视集群规模而定

（9）分布式队列

•  常规的先入先出队列。经过临时顺序节点实现。【2】经过getChildren()接口获取队列节点下的全部子节点，若是本身不是序号最小的子节点，进入等待，向比本身序号小的最后一个节点注册watcher监听。收集通知后，重复步骤【2】
• Barrier模型。屏障节点的数据内容存储n表明Barrier值。全部的客户端都会在屏障节点下建立临时节点，建立完毕获取屏障节点内容，【2】获取全部子节点，注册对子节点列表变动的watcher监听，统计子节点个数，不足barrier值，进入等待，收到watcher通知，重复步骤【2】

二、zookeeper在大型分布式系统中的应用

（1）hadoop。大型分布式计算框架

• 核心包括HDFS和MapReduce，分别提供了对海量数据的存储和计算能力。0.23.0版本开始，Hadoop又引入了全新一代MapReduce框架YARN。
• YARN是为了提升计算节点Master的扩展性，引入的全新一代分布式调度框架。支持多个计算引擎，包括MapReduce、Spark、Storm等
• YARN中最核心的ResourceManager，做为全局的资源管理器，负责整个系统的资源管理和分配。存在单点问题，使用Active/Standby模式，解决单点问题。只有一台处理Active状态，其余处于Standby状态，当Active节点挂掉以后，其他Standby节点会经过竞争选举产生新的Active节点
• zookeeper实现Active/Standby模式。相似于master选举，启动的时候都会去建立一个临时子节点，只要一个可以建立成功，成功的机器做为Active，其余的做为Standby，并注册子节点的watcher监听。一旦Active挂点，会话断开连接，临时节点自动删除，触发watcher，再次进行master选举出新的Active。
• HDFS的NameNode和ResourceManager模块都是使用该组件实现的HA
• 脑裂问题。选举出新的Active机器后，之前的Active恢复正常了，出现了脑裂现象。使用ACL权限控制来进行隔离，建立节点的同时增长修改这个节点的权限。当以前的Active机器恢复正常，尝试去修改节点数据的时候，发现已经没有了权限。

（2）HBase。是一个面向海量数据的高可靠性、高性能、面向列、可伸缩的分布式存储系统

• 与大多数分布式NoSQL数据库不一样的是，HBase针对数据写入具备强一致性、甚至包括索引列也都实现了强一致性
• HBase采用zookeeper服务来完成对整个系统的分布式协调工做
• 系统冗错。每一个RegionServer服务器都会信息节点，Hmaster对这个节点注册监听，当RegionServer挂掉以后，会话断开，节点被删除，Hmaster接收到删除通知，会将挂掉的RegionServer所处理的数据分片（Region）从新路由到其余的节点上。随着系统容量的不断增长，Hmaster管理的负担会愈来愈重，因此使用zookeeper来完成这部分工做，减轻Hmaster负担。
• RootRegion管理。数据存储的位置信息记录在元数据分片（RootRegion）上。客户端每次发起请求，须要知道数据的位置，就会去查询RootRegion。而RootRegion的位置存储在zookeeper上，当RootRegion发生变化或者发生故障时，就可以经过zookeeper感知到这一变化作出一系列响应的容灾措施。
• Region状态管理。Region是HBase中数据的物理切片，每一个Region中记录了全局数据的一小部分，不一样的Region之间数据不相互不重复的。对于一个分布式系统来讲，Region会常常变动，变动缘由来自于系统故障、负载均衡、配置修改、Region分裂和合并等。一旦Region发生移动，须要作上线和下线处理。状态管理须要Zookeeper来实现。对于Hbase集群来讲，Region的数量会达到10万级别。
• 分布式SplitLog任务管理。

 （3）Kafka。开源的分布式消息系统，是一个吞吐量极高的分布式消息系统。主要用于实现低延迟的发送和收集大量的事件和日志数据。

• 每一个broker服务器启动的时候，都会向Zookeeper注册。zookeeper做为注册中心
• 使用zookeeper做为他的分布式协调框架，实现了生产者和消费者的负载均衡

（4）dubbo

7、Zookeeper技术内幕

一、系统模型

• 数据模型。由数据节点Znode组成树型结构。每个事务操做（节点的建立和删除、数据节点内容变动、客户端会话的建立和失效）zookeeper会分配一个全局惟一的事务ID，ZXID，64位数字。前32位表示leader选举的届数，后32位表示事务序号
• 节点特性。持久节点，持久顺序节点，临时节点，临时顺序节点。节点除了存储数据，子节点以外，还存储了节点自己的一些状态信息，用Stat类来表示。
• 版本。版本信息也是存储在stat中的。version（当前节点数据内容的版本号）、cversion（当前节点子节点的版本号）、aversion（当前节点ACL变动版本号）。经过版本号来实现乐观锁，会从客户端请求中获取到版本号，和节点状态数据中存储的版本号对比，若是不匹配，就抛出异常。
• Watcher，数据变动的通知。客户端注册watcher的时候，会将watcher对象存储在客户端的watchManager中，当服务端触发watcher事件后，会向客户端发送通知，客户端线程从watchManager中取出对应的watcher对象来执行回调逻辑。watcher机制具备以下特色：一次性（不管是客户端仍是服务端，一旦一个watcher被触发，zookeeper就会从相应的存储中移除，因此须要反复注册）；客户端串行执行（客户端watcher的回调处理，是一个串行同步的过程，保证了顺序性，也须要注意watcher回调方法的处理，避免长时间执行而影响到其余的watcher回调）；轻量（只会告诉客户端发生了事件，不会说明事件的具体内容，另外，客户端注册的时候，也不会把客户端真实的watcher对象传递给服务器。如此轻量的设计，在网络开销和服务器内存开销上都是很是廉价的）
• ACL，权限控制。分为权限模式（Scheme）、受权对象（ID）、权限（Permission），使用scheme:id:permission来识别一个有效的acl信息
• Scheme说明。IP模式：“IP:192.168.1.24”，“IP:192.168.1.1/24”；Digest模式：username:password，会进行两次编码处理，分别是SHA-1算法和BASE64编码
• 受权对象（ID）。IP模式下是一个ip或一个ip段；Digest模式下，是username:password；World模型下，是“anyone”
• 权限（Permission）。create（C）建立子节点；delete（D）删除子节点；read（R）读取节点数据和子节点列表；write（W）更新节点数据；admin（A）节点管理权限，acl操做

二、序列化和协议

• jute介绍。是zookeeper的序列化组件，也是早期Hadoop中的默认序列化组件。后来因为Apache Avro具备出众的跨语言特性、丰富的数据结构和对MapReduce的天生支持，而且能很是方便的用于RPC调用，因此后来的Hadoop就抛弃了Jute。可是zookeeper因为新老版本兼容、性能瓶颈并不在jute上、其余需求优先级更高等缘由，一直使用着jute这个古老的序列化组件
• 通信协议。基于tcp/ip协议，zookeeper实现了本身的通信协议来完成客户端与服务端、服务端与服务端之间的网络通讯。请求包括请求头和请求体，响应包括响应头和响应体

三、客户端

 （1）一次会话的建立过程

• 初始化zookeeper对象
• 设置会话默认watcher
• 构造zookeeper服务器地址列表管理器：HostProvider
• 建立并初始化客户端网络链接器：ClientCncx。内部有两个线程，SendThread（I/O线程，负责负责zookeeper客户端和服务端之间的网络I/O通讯），ExentThread（事件线程，负责对服务器事件进行处理）。两个核心队列，outgoingQueue（客户端请求发送队列）、pendingQueue（服务端响应的等待队列），还会建立底层I/O处理器ClientCxcnSocket
• 初始化和启动SendThread，ExentThread
• 获取一个服务器地址，经过HostProvider获取
• 建立tcp长链接。ClientCxcnSocket负责建立一个tcp长链接
• SendThread负责构造一个ConnectRequest请求，放入到outgoingQueue请求队列中
• ClientCxcnSocket负责从outgoingQueue队列中取出一个待发送的对象，将其序列化成ByteBuffer后，发送给服务端
• ClientCxcnSocket接受服务器的响应，处理response，进行反序列化，
• 生成链接成功事件，交给ExentThread进行处理，从ClientWatcherManager查询watcher，将其放入到EventThread的waitingEvents队列中。
• 处理事件watcher，EventThread不断的从waitingEvents队列中取出待处理的watcher，调用watcher的process方法，执行回调逻辑。

（2）服务器地址列表

• 客户端隔离命名空间
• HostProvider，会把全部的地址列表打散成一个环形队列，不断的从这个队列中获取地址
• 自定义HostProvider，实现动态变动的地址列表管理器和同机房优先策略

四、会话

（1）会话状态。整个会话的运行期间，会在不一样的状态之间进行切换。这些状态包括connecting，connected，reconnecting，reconnected，close。

• 客户端因为网路缘由断开链接，会重连服务器。这个过程当中状态会在connecting和connected之间切换
• 会话超时、权限检查失败、客户端主动退出程序。这些状况下，客户端状态直接变为close

（2）session是zookeeper的会话实体。包含如下属性

• 会话ID。全局惟一的sessionid。sessionid计算算法：((System.currentTimeMillis()<<24)>>>8)|(id<<56)。当前系统时间左移24位再无符号右移8位，保证前8位都是0，用于来后边的服务器惟一表示id<<56作位或运算。前8位表示服务器机器id，后56位表示时间毫秒。sessionid由服务器进行建立，基于顺序执行的特定，因此全部客户端的请求的时间毫秒都是不同的。这样就保证了sessionid的全局惟一性。
• timeout。会话超时时间
• ticktime。下次会话超时时间点。用于分桶策略管理
• isclosing。标记一个会话是否已经关闭

（3）会话管理。由SessionTracker负责管理

• 分桶策略。按照ExpirationTime对会话进行分类，相似的会话放在同一区块中进行管理统一处理。ExpirationTime=（（currentTime+SessionTimeout）/ExpirationInterval+1）*ExpirationInterval。ExpirationInterval是leader服务器进行按期检查会话超时的时间间隔，默认值是tickTime的值。ExpirationTime老是ExpirationInterval的整数倍。
• 会话激活。当客户端向服务端发起请求的时候，会进行会话激活。从新计算会话的ExpirationTime。根据新旧两个下次超时时间点，进行会话迁移，完成会话激活。有两种状况会发生会话激活：1 是只要客户端发送了请求，就会触发一次会话激活；2 是若是客户端在sessionTimeout/3时间内未和服务器进行过任何通讯，就会主动向服务器发送ping请求（心跳检测），触发服务端的会话激活
• 会话超时检查，按照ExpirationTime时间线，对会话桶进行检查，留下的全部会话都是还没有被激活的，对他们进行批量清理
• 会话清理。标记会话状态为关闭，向集群中全部机器发起会话关闭请求，收集须要删除的临时节点，删除临时节点，移除会话，关闭链接

（4）会话重连

• 链接断开。connection_loss。客户端会自动从服务器地址列表中从新逐个选取新的地址尝试进行链接，直到最终成功链接上服务器。断开链接和重连成功，客户端都会受到服务端的事件通知
• 会话失效。session_expired。断开链接以后，重连期间耗时过长，超过了会话超时时间，服务器认为这个会话已经结束，进行会话清理。客户端不知道已经失效，若是以后客户端从新链接上了服务器，会受到会话已经失效的通知（session_expired）。
• 会话转移。session_moved。断开从新后，成功链接上了新的服务器，会话转移到了新的服务器上。

五、集群版服务器启动流程

（1）预启动

• 统一由QuorumPeerMain做为启动类
• 解析配置文件zoo.cfg
• 判断当前是集群模式仍是单机模式启动（集群模式中，在zoo.cfg中配置了多个服务器地址）

（2）初始化

（3）leader选举

（4）leader和follower启动期交互过程

• 建立leader服务器，建立follower服务器
• follower服务器和leader创建链接，注册follower
• leader服务器和follower服务器同步数据
• 过半follower服务器完成数据同步。
• 启动leader服务器和follower服务器

 六、leader选举

（1）选举概述。服务器启动时期的Leader选举

• 每一个server发出一个投票。初始化阶段都会投给本身。投票以（myid，ZXID）表示。
• 接收来自各个服务器的投票。判断投票的有效性、检查是不是本轮投票、是否来自looking状态的服务器
• 处理投票。把本身的投票和其余服务器的投票进行PK。PK规则：ZXID比较大的优先成为leader；ZXID相同，myid比较大的优先。把pk结果从新发给其余服务器
• 统计投票。每次投票后，都会统计是否有超过半数机器接收到相同的投票，大于等于n/2+1。
• 改变服务器状态。leader变为leading，follower变为following

（2）选举概述。服务器运行期间的leader选举

• 变动状态，当leader挂了以后，余下的非observer服务器都会讲本身的状态变为looking，开始进入选举过程。

• 在进行选举的过程当中，每台zookeeper server服务器有如下四种状态：LOOKING、FOLLOWING、LEADING、OBSERVING，其中出于OBSERVING状态的server不参加投票过程，只有出于LOOKING状态的机子才参加投票过程，一旦投票结束，server的状态就会变成FOLLOWER或者LEADER

• 选举过程同上。

（3）leader选举的算法分析。3.4.0版本开始，只保留了tcp版本的FastLeaderElection。废弃了LeaderElection和udp版本的FastLeaderElection

七、服务端请求处理

（1）会话建立请求

• 请求接收。I/O层接收请求，根据NIOServerCnxn是否初始化来判断是不是会话建立请求，反序列化请求，检查客户端Zxid（客户端Zxid需小于服务端Zxid），根据服务端的配置协商sessionTimeout
• 会话建立。为客户端生成sessionID，向sessionTracker中注册会话，会话激活，生成会话密码（做为会话在不一样服务器中间转移的凭证）
• 预处理。采用责任链模式，建立请求事务头、请求事务体、注册与激活会话（为了处理非Leader服务器转发过来的会话建立请求）
• 事务处理。Sync流程：Leader服务器和follower服务器记录事务日志的过程
• 事务处理。Proposal流程：投票和统计投票过程。相似于二阶段提交协议的preCommit。生成提议Proposal，广播提议，收集投票
• 事务处理。Commit流程：超过半数提议经过，广播commit消息
• 事务应用。将事务变动应用到内存数据库中，对于会话建立须要特殊处理，会话的管理由sessionTracker负责，只须要再次向sessionTracker注册便可
• 会话响应。统计服务端处理所花费的时间，建立响应，序列化响应，I/O层发送响应给客户端

（2）setData请求

• 预处理。接收请求，反序列化，会话检查、ACL权限检查、数据版本检查、生成事务
• 事务处理。同上
• 事务应用。将事务变动应用到内存数据库中
• 请求响应。同上

（3）事务请求转发。全部非Leader服务器收到了客户端发来的事务请求，都会将请求转发到Leader服务器来处理

（4）getData等非事务请求的流程

• 预处理。接收请求，判断是否为客户端会话建立请求，交给PrepRequestProcessor处理器进行处理，会话检查
• 非事务处理。反序列化请求，获取节点数据，ACL权限检查，注册Watcher
• 请求响应。同上

八、数据与存储

（1）内存数据

•  DataTree。是内存数据存储的核心，是一个树的结构。底层是ConcurrentHashMap<String,DataNode> nodes。节点的路径（path）做为key，节点的数据内容DataNode做为value
• DataNode。是数据存储的最小单元。包括节点的数据内容data[]、acl列表、节点状态（stat）、还记录了父节点的引用和子节点列表
• ZKDatabase。是zookeeper的内存数据库，负责管理zookeeper的全部会话、DataTree存储、事务日志。

（2）事务日志

• 文件存储。配置中的dataDir目录，是用来存储日志文件的。每一个日志文件的大小都是64M，以事务ID（ZXID）做为后缀，高32位表明Leader周期，低32位则是真正的操做序列号
• 日志内容存储格式。事务日志是二进制表示，没法直接看出信息。需使用事务日志格式化工具。org.apache.zookeeper.Server.LogFormatter。使用方法以下：Java LogFormatter 事务日志文件。须要注意的是，这是一个记录事务操做的日志文件，所以里面没有任务读操做的日志记录
• 日志写入。1.当前日志文件剩余空间不足4k，会进行预分配。文件的不断追加写入会触发底层磁盘I/O为文件开辟新的磁盘块（磁盘seek），为了不磁盘seek的频率，提升磁盘I/O效率；2.事务序列化；3.写入事务日志文件流；4.事务日志刷入磁盘
• 日志截断。非leader机器上记录的zxid比leader服务器还要大，Leader会发送TRUNC命令，进行日志截断，删除全部包含或大于peerLastZxid的事务日志文件

（3）snapshot，数据快照。用来记录Zookeeper服务器某一个时刻的全量内存数据内容，并将其写入到指定的磁盘文件中

• 文件存储。 经过dataDir来配置，快照文件也是用事务ID（ZXID）的十六进制做为文件后缀，该后缀标记了本次数据快照开始时刻的服务器最新ZXID。和事务日志不一样，快照日志没有采用预分配机制。
• 存储格式，和事务日志存储格式相同，须要使用格式化工具查看内容。会将数据节点逐个依次输出，这里输出的仅仅是数据节点的元数据（stat），并无输出每一个节点的数据内容
• 数据快照过程：1 判断是否须要进行数据快照（采用过半随机策略，避免全部机器同时进行数据快照，影响性能。logcount>(snapcount/2+randroll) snapcount是配置文件配置的数值，randroll是一个随机值）；2 切换事务日志文件，计数清零；3 建立数据快照异步线程； 4 获取全量信息和会话信息 ；5 生成快照文件名 6 数据序列化，写入磁盘

（4）初始化。服务器启动期间，会进行数据初始化过程，将磁盘上的数据加载到内存中

• 处理快照文件，获取最新的100个快照文件
• 对快照文件进行解析和校验。若是最新的快照文件未经过解析和校验，会逐个往下进行解析校验。
• 获取最新的ZXID
• 处理事务日志，获取全部大于上一步ZXID的事务日志。把事务日志应用到内存数据库中
• 再次获取最新的ZXID
• 校验epoch（leader选举届数）

（5）数据同步

peerLastZxID：该follower服务器最后处理的Zxid

minComminttedLog ：Leader服务器提议缓存队列ComminttedLog中最小的Zxid

maxComminttedLog：Leader服务器提议缓存队列ComminttedLog中最大的Zxid

• 直接差别化同步（DIFF同步）。peerLastZxID介于minComminttedLog和maxComminttedLog中间
• 先回滚在差别化同步（TRUNC+DIFF同步）。peerLastZxID介于minComminttedLog和maxComminttedLog中间，可是leader发现了某个follower包含了一条本身没有的事务记录。
• 仅回滚同步（RTUNC）。peerLastZxID大于maxComminttedLog
• 全量同步（SNAP）。peerLastZxID小于minComminttedLog；Leader没有提议缓存队列，peerLastZxID不等于Leader服务器最大的Zxid。在这两种状况下，Leader服务器都没法直接使用提议缓存队列和learner进行同步，所以只能使用全量同步（SNAP）

8、Zookeeper运维

一、配置详解

（1）基本配置。必需配置

•  clientPort：对外的服务端口，通常配置为218一、集群中的全部端口不须要保持一致
• dataDir：服务器存储快照文件的目录。dataLogDir，事务日志的存储目录
• tickTime：默认值3000毫秒，用于配置Zookeeper中最小时间单位的长度。会话的最小超时时间默认是2*tickTime

（2）高级配置

• dataLogDir：用于存储事务日志文件。应该将事务日志单独配置在一块磁盘上，事务日志写入的性能直接影响到zookeeper的性能和吞吐量。数据快照操做会极大的影响事务日志的写性能，尽可能分开磁盘
• initLimit：默认值为10，即tickTime的十倍。Leader等待follower完成数据同步的时间。随着集群的数据量增大，同步时间变长，能够适当调大这个参数
• syncLimit：默认值5，leader服务器和follower进行心跳检测的最大延时时间。若是网络环境较差，能够适当调大此参数
• snapCount：默认值 100000。两次快照之间间隔的事务操做次数
• preAllocSize：默认值65536，即64M。事务日志预分配的空间大小。随着snapCount的变化而变化，同增同减
• minSessionTimeout。maxSessionTimeout：最大和最小超时时间。分别是tickTime的2倍和20倍。用于对客户端回话超时时间进行限制
• maxClientCnxns：默认值60。若是设置为0，则表示没有限制。单个客户端和服务端之间的最大并发链接数。
• jute.maxbuffer：单个数据节点上存储的最大数据量大小。zookeeper上不须要存储太多的数据，每每还须要将该参数设置的更小
• clientPortAddress：针对多网卡的机器，zookeeper容许为每一个ip地址指定不一样的监听端口
• server.id:host:port:port：配置组成集群的机器列表。第一个port用于leader和follower进行通讯和数据同步的端口，第二个port用于leader选举过程当中的投票通讯
• autopurge.snapRetainCount：自动清理快照日志和事务日志时，须要保留的数量。最小值为3，默认值也是3
• autopurge.purgeInterval：自动清理的频率。默认值是0，单位是小时。配置为0或者负数，表示不开启自动清理功能。默认不开启此功能
• fsync.warningthresholdms：配置事务日志操做消耗时间的报警阈值，超过阈值，将在日志中打印出报警日志。
• forceSync：配置事务日志每次写入操做强制写入磁盘。默认值是yes。若是设置成no，在必定程度上能提升zookeeper的写性能，但存在断点的风险。
• globalOutStandingLimit：默认值1000，服务器最大请求堆积数量，防止服务器资源被大量的客户端请求耗尽。
• leaderServers：是否容许leader服务器向客户端提供服务。默认值yes。能够设置成no，让leader服务器专一的进行分布式协调
• SkipAcl：默认值 no。配置是否跳过acl权限检查。
• cnxTimeout：默认值5000毫秒。配置Leader选举过程当中，个服务器间tcp链接建立的超时时间
• eletionAlg：leader选举策略。3.4.0版本以后，只留下了fastLeaderElection算法。

二、四字命令

• conf。输出服务器的配置信息
• cons。输出这台服务器上全部客户端链接的详细信息
• crst。重置全部客户端的链接统计信息
• dump。输出当前集群中的全部会话信息。只有leader服务器会进行会话超时检测，leader服务器执行此命令，还会打印出会话的超时时间
• envi。输出当前服务器运行时的环境信息
• ruok。输出当前服务器是否正在运行。
• stat。输出当前服务器运行时的状态信息，包括链接状况
• srvr。和stat命令功能相同，区别是srvr命令不会打印链接状况
• srst。重置全部服务器的统计信息
• wchs。输出当前服务器上的watcher概要信息
• wchc。输出当前服务器上管理的watcher详细信息。以会话单元进行归组
• wchp。输出当前服务器上管理的watcher详细信息。以节点路径为单位进行归组
• mntr。输出比stat更详细的服务器统计信息。

三、JMX。是一个为应用程序、设备、系统等植入管理功能的框架

（1）开启远程JMX

经过上述配置，就能够容许远程机器和zookeeper服务器进行jmx链接了

（2）经过JConsole链接zookeeper

JConsole是一个Java内置的基于JMX的图形化管理工具，是最经常使用的JXM链接器。

四、监控

TaoKeeper监控系统，能够在实时监控和数据统计两方面保障Zookeeper的稳定性。github地址：https://github.com/alibaba/taokeeper

五、构建一个高可用的集群

（1）集群组成。最好的数量是奇数，不过偶数能够的

（2）容灾。三机房部署，2机房部署

（3）扩容与缩容。Zookeeper集群扩容须要整个集群机器的重启。总体重启和逐台重启

9、相关资料

Zookeeper的优缺点

zookeeper有什么缺点？