『互联网架构』软件架构-zookeeper场景和实现(34)

上次zookeeper的分布式也搭建完毕了,ZNODE,ACL,ZAB协议,Watcher,常用命令的使用,我们现在要怎么使用zookeeper呢?之前可能因为没接触过zookeeper,不知道他能干什么?通过场景来举个例子,zookeeper高可用分布式数据管理与协调框架,能分布式环境数据一致性,基于这样的特性我们来说说哪些场景实现。
源码:https://github.com/limingios/netFuture/ 【zookeeper】
https://github.com/limingios/netFuture/源码/【『互联网架构』软件架构-zookeeper场景和实现(34)】

(一)以电商系统为例

电商系统里面有很多的服务:会员系统,商品系统,交易系统。

  • 1.1场景
    >系统之间互相的调用,交易系统调用会员系统

假如:会员系统宕机了怎么办,正调用突然宕机了。交易系统因为调用的会员系统出现问题,直接影响到交易系统,调用红色的会员系统,都不能用,这个原因我们不知道,会员系统是不是可用,如果有个映射关系是不是更好一点。

考虑中间加入zookeeper的集群,我的会员系统对外提供一个查询基本信息的服务,服务告诉zookeeper,zookeeper拿到这个值。同时交易系统去zookeeper中看一下,问下zookeeper那些会员系统是可用的,zookeeper告诉我那个服务的(那台服务器)可用。也就是说我们需要让服务提供者会员系统在zookeeper中创建一个节点znode,上次说了znode,创建一个临时的节点,也就是说你这个节点down掉了,session就没有了,节点也就消失了。上次说过临时节点会通过客户端的关闭自动的删除,根据这个特点,是不是就可以每台机器都注册一个服务,服务是一个节点,当这台机器宕机后,这个节点就自然的消失了。

通过zookeeper的临时节点获取到可用的服务器后就开始使用会员系统,但是在单独指向会员系统的时候,会员系统突然宕机了。交易系统又需要在去寻找新的可用的会员系统,凡是出现红色的,都是不能用了,zookeeper的特性watcher,回调方法,如果会员系统宕机了,就告诉交易系统重新去订阅。这块就是一个服务注册。

  • 1.2 分布式服务注册与订阅
    >在分布式环境中,为了保证服务的高可用,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务,而消费者就需要在对等服务器中选择一个来执行相关的业务逻辑,比较典型的服务注册与订阅,消费者与生产者(负载均衡类似方案)。
    >总结:系统之间存在某种订阅关系。其实dobbo就是这个原理

####(二)源码演示
* 2.1步骤

#启动zk
cd /root/zookeeper-3.4.10/bin
sh zkServer.sh start

#客户端建立文件夹
sh zkCli.sh -server 192.168.69.101:2181,192.168.69.102:2181,192.168.69.103:2181
#创建根节点
create  /tl myData 

  • 2.2导入项目每个项目都install

  • 2.3运行memberserver

  • 2.4 保证运行memberserver正在运行的时候,可以运行OrderClient

  • 2.5功能介绍
    >通过zk客户端创建好根节点后,保证linux的zk正在运行,启动服务端,java会自动创建临时节点,订单可以直接访问,如果服务端关闭的话,临时节点自动消失。

PS:本次主要针对场景进行了,本身zk都是分布式框架,它很少存在宕机的情况,除非外在因素,例如内存硬盘爆了。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:『互联网架构』软件架构-zookeeper场景和实现(34)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注