zookeeper

概念

开源的分布式应用程序协调服务，以fast paxos（一致性） 算法为基础，实现同步服务，配置，和命名等。

作用

1. 将强集群稳定
2. 加强集群持续性
3. 保证集群有序性
4. 高效

其他项目中的作用：其他项目中的作用：

保证只有一个主节点，存储配置信息。
例如，在Hbase 中，保证只有一个hmaster，监控hregionServer的联机和宕机，存储访问控制列表等。

特点

集群节点数一般为奇数(2n+1)，因为Zookeeper投票需要超过半数，所以最好使用奇数个机器。

例如，使用四台机器，ZooKeeper只能处理单台机器的故障;
如果两台机器出现故障，其余两台机器不会占多数，集群无法正常运行。
容错跟三台是一样的，浪费资源。
如果想配置能容n台的集群，至少需要 2n+1 台机器，组成集群。

最好能够为每台机器配置互相独立的硬件环境。如果大部分的机器都挂在同一个交换机上，那么这个交换机一旦出现问题，集群就肯能瘫痪。
集群一般设置一个交换机的小集群+Observer节点。
集群如果扩大，节点变多，选举leader变慢。Observer不投票，跟随结果，其他功能跟follower一样。所以一般是通过Observer扩展集群。

选举机制

Leader选举是保证分布式数据一致性的关键。
选举情景：

• 集群启动
• 上一任leader 挂了
  选举规则：
• zxid > myid
• zxid相同就比较myid大小
  感觉跟人很像，就是先比资格，谁资格高谁就能当leader，资格相同了就比能力，能力强的当，强者才拥有补兵的权利。

Leader选举，则至少需要两台机器，选举过程如下：

1. 投票
   群龙无首，都相当老大，好坐拥后宫。每台机器都投自己，然后各自将这个投票发给集群中其他机器。
2. 验证
   收到投票后，首先判断该投票的有效性,是不是假的，有没有冒充。
3. 更新投票
   根据选举规则，筛选。被征服者就将自己的票改成征服者的，继续投票。
4. 统计投票
   每次投票后，服务器都会统计投票信息，判断是否已经有过半，超过半数，认为已经选出leader，停止投票。
5. 改变状态
   确定了Leader，每个服务器就会更新自己的状态，leader => leading 其他的 following;

在Zookeeper运行期间，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader（猴子实验），但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致（多一个变更状态从开始的following变成looking）。

提高

默认情况下，ZK的数据文件和事务日志是保存在同一个目录中，建议是将事务日志存储到单独的磁盘上。
因为当zookeeper集群进行频繁的数据读写操作是，会产生大量的事务日志信息，ZK都会在确保事务日志已经落盘后，才会返回客户端响应。因此事务日志的输出性能在很大程度上影响ZK的整体吞吐性能。

故障处理

ZK在启动的过程中，首先会根据事务日志中的事务日志记录，从本地磁盘加载最后一次提交时候的快照数据，如果读取事务日志出错或是其它问题（通常在日志中可以看到一些IO异常），将导致server将无法启动。碰到类似于这种数据文件出错导致无法启动服务器的情况，一般按照如下顺序来恢复：
1、确认集群中其它机器是否正常工作，方法是使用“stat”这个命令来检查：echo stat|nc ip 2181
2、如果确认其它机器是正常工作的，那么可以开始删除本机的一些数据了，删除$dataDir/version-2和$dataLogDir/version-2
两个目录下的所有文件。 重启server。重启之后，这个机器就会从Leader那里同步到最新数据，然后重新加入到集群中提供服务。