Zookeeper集群安装

Zookeeper集群安装


zookeeper 配置文件详解

参数	说明
clientPort	客户端连接server的端口，即zk对外服务端口，一般设置为2181
dataDir	就是把内存中的数据存储成快照文件snapshot的目录，同时myid也存储在这个目录下（myid中的内容为本机server服务的标识）。写快照不需要单独的磁盘，而且是使用后台线程进行异步写数据到磁盘，因此不会对内存数据有影响。默认情况下，事务日志也会存储在这里。建议同时配置参数dataLogDir, 事务日志的写性能直接影响zk性能。
tickTime	ZK中的一个时间单元。ZK中所有时间都是以这个时间单元为基础，进行整数倍配置的。例如，session的最小超时时间是2*tickTime，默认3000毫秒。这个单元时间不能设置过大或过小，过大会加大超时时间，也就加大了集群检测session失效时间；设置过小会导致session很容易超时，并且会导致网络通讯负载较重（心跳时间缩短）
dataLogDir	事务日志输出目录。尽量给事务日志的输出配置单独的磁盘或是挂载点，这将极大的提升ZK性能。 由于事务日志输出时是顺序且同步写到磁盘，只有从磁盘写完日志后才会触发follower和leader发回事务日志确认消息（zk事务采用两阶段提交），因此需要单独磁盘避免随机读写和磁盘缓存导致事务日志写入较慢或存储在缓存中没有写入

initLimit	Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。Leader允许Follower在initLimit时间内完成这个工作。通常情况下，我们不用太在意这个参数的设置。如果ZK集群的数据量确实很大了，Follower在启动的时候，从Leader上同步数据的时间也会相应变长，因此在这种情况下，有必要适当调大这个参数了。默认值为10，即10 * tickTime  (No Java system property)
syncLimit	在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。如果Leader发出心跳包在syncLimit之后，还没有从Follower那里收到响应，那么就认为这个Follower已经不在线了。注意：不要把这个参数设置得过大，否则可能会掩盖一些问题，设置大小依赖与网络延迟和吞吐情况。默认为5，即5 * tickTime (No Java system   property)

server.x=[hostname]:n:n

这里的x是一个数字，与myid文件中的id是一致的，用来标识这个zk server，大小为1-255。右边可以配置两个端口，第一个端口用于Follower和Leader之间的数据同步和其它通信，第二个端口用于Leader选举过程中投票通信。Zk启动时，会读取myid中的值，从而得到server.x的配置为本机配置，并且也可以通过这个id找到和其他zk通信的地址和端口。hostname为机器ip，第一个端口n为事务发送的通信端口，第二个n为leader选举的通信端口，默认为2888:3888。(No Java system property)

配置文件实例

---

启动zookeeper，并验证是否正常启动

# 启动zk
$ ./zkServer.sh start

# 查看zk状态
$ ./zkServer.sh status

# 检查是否正常运行
$ echo ruok | nc localhost 2181
iamok

Zookeeper释义
理解zk的一种方法就是将其看作是一个具有高可用性的文件系统，但是这个文件系统没有文件和目录，而是统一使用“节点”的概念，称为znode。znode既可以作为
保存数据的容器，如同文件，也可以作为保存其他znode的容器

ZK通常以“复制模式”运行于一个计算机集群上，ZK通过复制来实现高可用性，只要集合中半数以上的机器处于可用状态，它就能够提供服务。例如有5台机器，任意
两台出现故障，都可以保证服务继续；再例如6台机器的集群也只能容忍两台出现故障，因为如果3台出现故障，剩下的3台没有超过集群总数的半数，出于这个原因，一
个集群通常包含奇数台机器

Zookeeper从概念来说非常简单，它所做的就是确保znode树的每一个修改都会被复制到集群中超过半数的机器上。如果少于半数的机器出现故障，则最少有一台机器会
保存最新的状态。其余的副本最终也会更新到这个状态

Zookeeper实现机制
1 领导者选举
集合体中的所有机器通过一个选择过程选出一台称为“领导者”的机器，其他的机器称为“跟随者”。一旦半数以上的跟随者已经将其状态与领导者同步，则表明这个阶段
已经完成
2 原子广播
所有的写请求都被转发给领导者，再由领导者将更新广播给跟随者。当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新
成功的响应。这个用来达成共识的协议被设计成具有原子性，因此每个修改要么成功要么失败


待续。。。。。。