zookeeper系列(二) 节点讲解以及实际项目运用

zookeeper系列(二) 节点讲解以及实际项目运用_第1张图片

前言:最近工作不是很忙,本应该乘着闲暇的时间看书的,之前每天晚上都要翻翻的,可是自己竟然迷恋上了王晓磊 写的 卑鄙的小人-曹操传  刚开始的时候还没啥 后面迷的无法自控,以前中午吃完饭的时候,都是趴着玩手机,现在是一吃完饭都是拿着kindle看上一会儿,弄的技术书好久都没翻过 连博客也不写了,实在不该,罪过罪过 ,一个技术狗 不搞技术,那不是坐着等死吗。话不多说,回归正题。

    前段时间 我给大家介绍了ZK的一些基础知识,让大家对ZK有了一个初步了解,但在实际的过程中 怎么将zk运用到实际的项目中去了 zk的节点有几种特点,以及如何调整好我们的zk配置 才能达到最优了 今天我给大家简单的介绍一下。

我们以我们的实际项目为例 给大家介绍一下。 场景:我们有两个直播房间服务yunva-room,用户登入房间,根据yunva-room-lvs服务将房间里的用户分部在不同的服务机器上,即不同的服务器有相同的房间,房间里有不同的用户。那么这时候问题就来了

1 分布在不同服务器上的相同房间怎么保证用户数负载均衡  ?

2  一台机器的房间服务挂掉后,另一台服务器怎么感知?

此时ZK的出现 可以很好的解决这两个问题。

解决方式: 1  将不同服务器上房间用户的数据都挂在ZK上,根据zk的数据的变化 动态的将用户分配在合适的机器上。

                  2  ZK的临时节点的变化,ZK是可以感知的,可以通知到其他的临时节点,这样就很好的解决一台服务挂掉后,很好的通知到另几台房间服务所在的服务器。将缓存在本地的可用房间服务列表清掉即可。

不同服务器上的房间服务启动后,向ZK注册自己的房间服务信息并建立节点 配置的信息写在配置文件上


zookeeper系列(二) 节点讲解以及实际项目运用_第2张图片

服务启动后向zk注册 并订阅监听子节点时间,接受其他房间服务挂掉的通知:

RoomServerInfo 和 ServiceInfo 是我们房间服务 节点 的基本配置信息

zookeeper系列(二) 节点讲解以及实际项目运用_第3张图片

yunva-room 服务启动后都会向zk注册,zk里的节点信息如下:

zookeeper系列(二) 节点讲解以及实际项目运用_第4张图片

roomServer节点下面都是我们的不同的房间服务  房间里面的数据大家大家也是可以看得到的。

yunva-room-lvs 服务启动后  会向zk订阅所有的房间服务 进行用户的分配 达到负载均衡。订阅房间服务的时候,全部load到本地缓存中,如果子节点发生变化了,则从本地缓存中移除挂掉的服务数据。也就不进行用户的分配。

zookeeper系列(二) 节点讲解以及实际项目运用_第5张图片

当我们的房间服务挂掉后 我们的节点也就发生了变化,在此之前,我们简单的介绍一下ZK的节点相关知识,

ZK的节点是有生命周期的,可以分为以下几种节点:

持久节点(PERSISTENT)

所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。

临时节点(EPHEMERAL)

和持久节点不同的是,临时节点的生命周期和客户端会话绑定。也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉。注意,这里提到的是会话失效,而非连接断开。另外,在临时节点下面不能创建子节点。

我们创建的节点肯定是临时的,服务挂掉后,子节点也就消失了 ZK感知后 通知到订阅节点变化的服务yunva-room-lvs 从本地移除到没有用的服务。

回归到如何监听节点 我们用的zk 是用开源的curator框架来进行对zk操作,这个比较成熟,还有一些类似其他的vertx spring-clound 都有对zk的封装 ,大家如果有时间的话 可以看一下 挺有意思的。

那么curator 监听的节点三种方式:

1 PathChildrenCache  PathChildrenCacheListener 监听子节点变化

实现类似如下:

zookeeper系列(二) 节点讲解以及实际项目运用_第6张图片

2 NodeCache NodeCacheListener 监听父节点变化 如下:

zookeeper系列(二) 节点讲解以及实际项目运用_第7张图片

3 TreeCache TreeCacheListener 监听父节点和子节点的变化 如下:

zookeeper系列(二) 节点讲解以及实际项目运用_第8张图片

在我们的项目中肯定用的是监听子节点变化 能感知服务是否可用

我们监听子节点的方式  订阅子节点变化的时候 我们用了java 的观察者模式  有变化 通知到实际的服务

zookeeper系列(二) 节点讲解以及实际项目运用_第9张图片

上面我们讲到了 我们要实现不同服务器的房间用户负载均衡,房间人数是要挂到ZK服务上去的,并且要实现负载均衡算法。 由于yunva-room-lvs 监听节点了变化  每次用户登入房间 zk节点发生变化 并同步到yunva-room-lvs 即不同服务器上的房间人数也同步到了本地缓存  负载均衡 根据yunva-room-lvs 本地缓存的房间数据来进行分配房间的服务器分配即可。

用户登入房间 yunva-room感知后  向zk伪实时(2分钟同步一次)同步数据:


zookeeper系列(二) 节点讲解以及实际项目运用_第10张图片

yunva-room-lvs 进行用户服务器的分配

zookeeper系列(二) 节点讲解以及实际项目运用_第11张图片

    本想给大家继续介绍在ZK服务实际在生产环境的优化配置  使ZK达到最好的状态 今天就到这里吧 我都没吃饭 在公司默默的码字。 今天简单的介绍了zk在实际项目中的运用以及zk节点以及如何监听的基本知识,后面我给大家介绍ZK的生产环境优化我们的配置  以及其他的一些知识  比如分布式锁  分布式队列 我们这个项目已经在线上稳定运行。是一个很好的例子  而且我们的并发还很高。 

      不多说了  该回去吃狗粮了  不然猝死在办公桌上都没人收尸,我是小志码字,一个简单码代码的小人物。如果想了解这个项目和代码  加我微信  微信号:2B青年  欢迎交流 相互学习。

你可能感兴趣的:(zookeeper系列(二) 节点讲解以及实际项目运用)