【金三银四】Zookeeper常用场景使用介绍

Zookeeper主要是基于文件系统和监听通知机制,可以用于统一命名服务、分布式配置管理、集群管理、分布式锁、分布式队列、负载均衡等功能。

文件系统结构

Zookeeper维护一个类似文件系统的数据结构: 每一个子目录,如NameService称之为一个znode目录节点,和文件系统一样,我们可以对znode节点进行添加、删除操作,在znode的子节点下添加删除操作,唯一的不同是znode是可以保存数据的,数据还包含当前版本、数据版本、建立时间和修改时间等

数据类型

Zookeeper支持四种类型的节点数据: 持久化目录节点(persistent):客户端与zookeeper断开连接后,该节点依然存在 持久化顺序编号目录节点(persistent_sequential):与持久化目录节点一样,不过Zookeeper给该节点进行顺序编号 临时目录节点(ephemeral):客户端与zookeeper断开连接后,该节点被删除 临时顺序编号目录节点(ephemeral_sequential):与临时目录节点一样,不过Zookeeper给该节点进行顺序编号

监听通知机制

客户端监听它所关心的目录节点,当目录节点发生变化(数据改变、删除、子目录节点发生变化)的时候,zookeeper会通知客户端,在Zookeeper中,默认有二种角色,Follower、Leader,一个Zookeeper集群在同一时刻只会有一个Leader,其余都是Follower,我们还可以添加Observer角色,如果想使用Observer模式,在任何想变成Observer的节点的配置文件中加入:peerType=Observer。Leader服务器可以为客户端提供读和写操作,而Follower和Observer都只能提供读服务,唯一的区别是Observer不参与Leader选举过程,也不参与写操作(过半写成功)策略,因此Observer可以在不影响写性能的情况下提升集群的读性能。

应用场景

Zookeeper所有的功能都是基于文件系统和监听通知机制来完成的,下面来讲解一下各个功能的实现原理:

分布式配置管理

在大型系统中,我们部署的项目可能超过上百台机器,当我们在修改配置的时候,不可能每一台机器都去修改一下,这样维护起来太复杂了,所以我们可以将配置文件通过Zookeeper来管理,在Zookeeper中创建一个Configuration的目录节点,所有应用程序都监听这个目录节点,一旦配置文件的信息发生变化,Zookeeper会通知每个应用,然后每个应用从Zookeeper中获取最新的配置信息。

Zookeeper集群环境

如上图,我们在三台服务器上部署了Zookeeper的集群环境,在三台机器的Zookeeper启动完成后,会选举一台机器为Leader,负责客户端的的读和写请求,其他两条机器为Follower,只能负责读请求 场景模拟:当我们通过zkclient在192.168.1.1的机器上创建了一个/hello的数据节点,会发现这台Follower也能写成功,并且在192.168.1.2或者192.168.1.3的机器上都能够获取到,那么是不是就与上面的Follower只能负责读理论冲突了?其实并没有冲突,而是Follower在接受到写请求后,它会将写请求转给Leader节点,让Leader节点去处理写请求,Leader写成功后会通知同步到各个Follower节点,这样做的目的是保证数据的唯一性,过程如下: 1、 Client向Follower发起一个写请求 2、 Follower把写请求转发给Leader 3、 Leader接收到请求以后开始发起投票并通知Follower进行投票 4、 Follower把投票结果发送给Leader 5、 Leader将结果汇总,发现如果超过一半的节点支持写入,那么投票成功,则开始写入同时把写入操作通知给Follower,然后commit 6、 Follower把请求结果返回给Client

集群选举原理

还是拿上面的写请求作为分析案例,当我们的Follower向Leader发送一个写请求后,会在Leader节点生成一个全局唯一的严格保证顺序递增的事务ID(ZXID),因为读不会有事务的概念,写才有事务的概念,生成后Leader节点会向所有的Follower节点服务器发送请求,并且所有的Follower服务器会发送一个收到事务通知的确认消息到Leader服务器,只要Leader服务器收到超过一半的Follower服务器发过来的确认消息,Leader服务器就可以开始做Commit操作,同时也通知其他Follower服务器做Commit操作,这样在一台Follower服务器上写数据后,其他服务器都能够同步更新,这里面涉及到两阶段提交,这样做的目的是保证了数据的一致性,性能也比较高。 如果其中Leader节点因为某种原因而导致服务器挂了,那么如何保证高可用呢,Zookeeper会通过集群选举一个新的节点作为Leader节点,实现如下:当Leader节点不可用的时候,所有的Follower节点会向集群中其他的存活的Follower节点发送投票消息,该消息格式为(myid,zxid),每台服务器当然是优先投自己,其中myid为集群搭建的时候我们自己配置的,zxid为该服务器最新的zxid,每台机器的zxid由于受到Leader消息的前后可能会不一样,当每台机器接受到来自不同Follower发送的消息后,根据最大的zxid进行pk,谁的最大,谁的票数最多,然后其他的票数作废,因为最大的zxid的服务器肯定能保证数据是最新最全的,当每台服务器选举出来结果后会做更新操作,同时会向其他服务器发通知,其他服务器收到投票通知后,当其中一台服务器得到的票数大于总服务器数的一半,那么该服务器就成功选举成为Leader,所以我们在搭建集群环境的时候,最好搭建的集群数量为奇数,集群Leader选举和集群消息广播(两阶段提交)的组合就是zab原子广播协议。Zookeeper没有用到paxos算法来保证数据一致性,zab协议其实是paxos算法的一个变种。

分布式锁

分布式锁主要用于在分布式环境中保护跨进程、跨主机、跨网络的共享资源实现互斥访问,以达到保证数据的一致性。Zookeeper实现分布式锁是通过持久节点和临时顺序节点来完成的,实现思路如下: 1、 在指定目录下创建一个持久节点,例如lock节点(zookeeper里面的znode节点会自动同步,而且是强一致性的,创建一个节点后只有zookeeper集群同步完成后才算成功) 2、 每当进程需要访问共享资源的时候,会在lock下面建立响应的顺序临时子节点,例如tmp_node1、tmp_node2、tmp_node3 3、 建立临时顺序子节点后,判断建立的子节点的顺序号(临时子节点创建会自动生成一个顺序号)是否为最小节点,如果是最小节点,就可以获得锁对资源进行访问 4、 如果该节点不是最小节点,那么就获得该节点的上一个顺序节点,并给该节点注册监听事件监听 5、 当客户端关闭与zookeeper连接之后,会删除当前的临时子节点,释放当前的锁,下面的临时节点会得到通知,并判断自己的节点是否为当前最小的,如果是则获取共享锁,如果不是则继续第4步对比自己小的节点注册监听事件 流程如下:

0评论