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

原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『互联网架构』软件架构-zookeeper场景和实现（34）

上次zookeeper的分布式也搭建完毕了，ZNODE，ACL，ZAB协议，Watcher，常用命令的使用，我们现在要怎样使用zookeeper呢？之前可能由于没接触过zookeeper，不知道他能干什么？通过场景来举个例子，zookeeper高可用分布式数据管理与协调框架，能分布式环境数据一致性，基于这样的特性我们来说说哪些场景实现。
源码： limingios/netFuture/ 【zookeeper】
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步骤

#启动zkcd /root/zookeeper-3.4.10/binsh 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都是分布式框架，它很少存在宕机的情况，除非外在因素，例如内存硬盘爆了。