Zookeeper为什么一般要部署奇数台服务器？

Zookeeper为什么一般要部署奇数台服务器？

这个问题，猛一看有点无从下手，其实考察的就是Zookeeper的选举机制。

首先要明确一点，任意台Zookeeper服务器都能够部署且正常运转。Zookeeper官方建议部署奇数台服务器，其实是基于节约资源的角度来考虑的。

Zookeeper默认采用Quoryms组件来处理集群的脑裂问题。Quoryms的原则就是过半存活即可用。

假如我们需要搭建一个最大允许N台服务器宕机的Zookeeper集群，那么我们最少需要部署2N+1台服务器。也就是说，对于一个有2N+1台服务器服务器的Zookeeper集群来说，最大能接受N台服务器宕机。那么，有兄弟会说，我部署2N+2台服务器也可以满足你的要求。是的，2N+1只是一个最优解。Zookeeper官方建议部署奇数台服务器，就是从资源利用率的角度来说的。毕竟，服务器资源的成本是比较大的，能少部署1台，就节约1台的成本。

在公司核心系统的开发过程中用到了ZooKeeper，简称zk，用于搭建分布式核心环境，开发过程中也经常会遇到zk出现的问题，看了几篇博客了解和总结一下zk的基本原理。

ZooKeeper 主要有几个重要的概念，简单总结下：

ZooKeeper 中主要有三种角色：Leader、Follower、Observer

一个 ZooKeeper 集群同一时刻只会有一个 Leader，其他都是 Follower 或 Observer。

ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。

Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。

每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。 

Session 是指客户端会话。在ZooKeeper 中，一个客户端连接是指客户端和 ZooKeeper 服务器之间的TCP长连接。

ZooKeeper 对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的 Watch 事件通知。

Session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

zookeeper的结构其实就是一个树形结构，leader就相当于其中的根结点，其它节点就相当于follow节点，每个节点都保留自己的内容。

zookeeper的节点分两类： 持久节点 和 临时节点

持久节点：所谓持久节点是指一旦这个 树形结构上被创建了，除非主动进行对树节点的移除操作，否则这个 节点将一直保存在 ZooKeeper 上。

临时节点：临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

有四种类型的znode： 

1、PERSISTENT-持久化目录节点 

客户端与zookeeper断开连接后，该节点依旧存在 

2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 

3、EPHEMERAL-临时目录节点 

客户端与zookeeper断开连接后，该节点被删除 

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 

每个 节点除了存储数据内容之外，还存储了 节点本身的一些状态信息。用 get 命令可以同时获得某个 节点的内容和状态信息

在 ZooKeeper 中，version 属性是用来实现乐观锁机制中的『写入校验』的（保证分布式数据原子性操作）。

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，为了保证事务的顺序一致性，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。

ZooKeeper允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。该机制是 ZooKeeper 实现分布式协调服务的重要特性。

---