认识Zookeeper
ZooKeeper: A Distributed Coordination Service for Distributed Applications
ZooKeeper是分布式应用的开源协调服务。它公开了一组简单的原语,分布式应用程序可以在实现更高级别的同步、配置维护、组和命名的基础上进行构建。它被设计成易于编程,并使用一个数据模型,它采用了熟悉的文件系统目录树结构。它在Java中运行,并且对Java和C都有绑定。众所周知,协调服务很难得到正确的结果。他们特别容易犯诸如竞态条件和死锁等错误。ZooKeeper的动机是减轻分布式应用程序从头开始执行协调服务的责任。
Design Goals(设计目的)
为单点故障。严格的排序意味着复杂的同步原语可以在客户端实现
ZooKeeper is replicated
与它所协调的分布式进程一样,ZooKeeper本身也要在一组名为“集成”的主机上进行复制
官网上图片,便于各位理解
组成Zookeeper的各个服务器必须互相了解。它们维护状态的内存映像,以及持久存储中的事务日志和快照。只要有大多数服务器可用,
就可以使用ZooKeeper服务。
客户端连接到一个ZooKeeper服务器。客户端维护一个TCP连接,通过它发送请求、获取响应、观看事件和发送心跳。
如果连接到服务器的TCP连接中断,客户端将连接到另一个服务器
ZooKeeper is ordered:
ZooKeeper用一个数字来标记每个更新,它反映了所有动物管理员交易的顺序。后续的操作可以使用命令来实现更高级别的抽象,例如同步原语。
ZooKeeper is fast:
它在“读占主导”的工作负载中尤其快速。ZooKeeper的应用程序运行在成千上万台机器上,而且它的性能最好,比写的更常见,在10:1左右。
Data model and the hierarchical namespace:
与标准的文件系统不同,Zookeeper名称空间中的每个节点都可以与之关联的数据以及孩子。这就像有一个文件系统,它允许一个文件也是一个目录。(管理
员旨在协调数据存储:状态信息,配置、位置信息等,所以在每个节点存储的数据通常是小,在千字节的字节范围。)我们使用术语znode说清楚,我们谈论的是
Zookeeper的数据节点。
Zookeeper的集群配置
zookeeper 下载地址:下载zookeeper
第一步:主机名称到IP地址映射配置
ZooKeeper集群中具有两个关键的角色:Leader和Follower。集群中所有的结点作为一个整体对分布式应用提供服务,集群中每个结点之间都互相连接,所以,在配置的ZooKeeper集群的时候,每一个结点的host到IP地址的映射都要配置上集群中其它结点的映射信息。
例如,我的ZooKeeper集群中每个结点的配置,以slave-01为例,/etc/hosts内容如下所示:
192.46.31.xx slave-01
192.46.32.xx slave-02
192.46.33.xx slave-03
ZooKeeper采用一种称为Leader election的选举算法。在整个集群运行过程中,只有一个Leader,其他的都是Follower,如果ZooKeeper集群在运行过程中Leader出了问题,系统会采用该算法重新选出一个Leader。因此,各个结点之间要能够保证互相连接,必须配置上述映射。
ZooKeeper集群启动的时候,会首先选出一个Leader,在Leader election过程中,某一个满足选举算的结点就能成为Leader。整个集群的架构可以参考http://zookeeper.apache.org/doc/trunk/zookeeperOver.html#sc_designGoals。
第二步:修改zoo.cfg
打开zookeeper-3.4.3old\conf\zoo.cfg
在最后加入:
server.1= slave-01:2888:3888
server.2= slave-02:2888:3888
server.3= slave-03:2888:3888
上述配置内容说明,可以参考 http://zookeeper.apache.org/doc/trunk/zookeeperStarted.html#sc_RunningReplicatedZooKeeper
第三步:把修改好的zoo.cfg替换到另外两台服务器的相同路径下
第四步:设置myid
在另外两台服务器上也如此配置。
启动zookeeper 集群
zookeeper 选举算法:fastLeader.现假设有1-5台服务器
服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.