『互联网架构』软件架构-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步骤

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