Zookeeper服务端
目录
服务运行模式
集群中的机器数量
Session连接
Zookeeper的安装
Zookeeper的session状态流转
集群化部署
服务运行模式
可以是单体服务，也可以是集群服务。
单体服务只有一台服务器，没有备份，没有状态同步。
集群服务有多台服务器，避免单点故障导致的不可用问题，存在备份，存在状态同步。通常更倾向于集群模式。
集群中的机器数量
我们在搭建Zookeeper集群（其他集群也可以参考）时，该如何考虑服务节点的数量呢？这里的节点我们在机器的维度考虑。
一般采用半数可用的原则，即，如果有五个机器提供服务，那么至少要有三台可用，即容忍有2台机器同时down掉。在客户端的单次操作请求时，至少要完成三台机器上的数据持久化才能告知客户端操作成功。半数可用原则为高可用提供了基础。
同时，我们往往将服务节点数设置为奇数个，便于提高可用性。
Session连接
在客户端调用服务端时，先建立session，这个session的含义非同小可。
首先，临时节点会因为session的断开而消失（被删除）
其次，session代表的是一次TCP链接，通过链接传递数据。
再次，单个session执行的api操作是有序的。
Zookeeper的安装
前提：
已经安装java 1.6以上版本
1. 下载安装文件
下载链接
https://zookeeper.apache.org/
2. 解压
tar -xvzf zookeeper-3.4.5.tar.gz
3. 重命名默认配置
mv conf/zoo_sample.cfg conf/zoo.cfg
4. 可以修改一下zoo.cfg中的数据存储位置配置
dataDir=/users/me/zookeeper
5. 启动服务端
bin/zkServer.sh start
上述语句默认后台启动，也可以使用下面的命令前台启动
bin/zkServer.sh start-foreground
6. 启动客户端
bin/zkCli.sh
7. 查看节点
ls /
8. 创建节点
create node data
9. 删除节点
delete node
10. 停止服务
bin.zkServer.sh stop
Zookeeper的session状态流转
1：客户端初始化时，未连接->连接中
2：连接建立成功，连接中->已连接
3：当客户端丢失服务端的链接，或者持续一段时间没有接受到服务端的响应，已连接->连接中
2：当持续一段时间无法接受服务端的响应时，客户端开始尝试换个服务器重连，此时链接成功的话，连接中->已连接
4：连接超时，无法重连，连接中->关闭
4/5：客户端可以主动关闭连接
在创建链接的时候，需要指定超时时间t，这个t代表从上一次接收到消息开始到断开连接的时间。
当到达1/3的t的时间还没有接收到服务端的响应时，客户端开始发送心跳包。
当到达2/3的t的时间还没有回应时，客户端开始选择换一个服务器重连。
同时，zookeeper通过zxid来保证更新的顺序，保证已经同步状态的服务器才能接受客户端的重连，而状态滞后的服务器是不能建立连接的。
集群化部署
我们可以在单个服务器上配置多个zookeeper实例，模拟集群化
1. 创建三个目录，z1，z2, z3，在三个目录下创建data目录，在data目录下创建myid文件
通过公共化配置服务，server.1 server.2 server.3表示三个节点，2222和2223分别用于通信和master选举，2181是客户端链接端口。
2. 给三个myid存储初识数据，表示自己的唯一编号：
3. 启动第一个节点：
这里的报错表示连接其他服务器失败，因为只启动了一个节点，所有失败是正常的
4. 启动第二个节点
发现节点2被选举为master
此时节点1的日志也体现了节点1变成了从节点
5. 客户端建立连接
指定server来指定集群的服务器。
我们发现连接到了节点2，实际上节点3并未启动，因此会发现偶现失败连接到3，重新自动连接到节点1或者节点2的情况。