读码农翻身之Zookeeper

1、分布式RPC存在的问题
假如后端的订单服务提供了四台服务器给客户端使用，而客户端使用的是配置文件的方式配置了后端服务的地址，那么问题就出现了，如果后台的订单服务故障或者新增了新的服务器，客户端是无法实时知道的，这就导致服务不稳定。

2、抽象一***册中心
可以考虑提供一个注册中心，客户端如果需要服务时，直接请求注册中心来获取。而注册中心返回一个可用的地址。

这个注册中心的数据结构如果设计为树形结构，如下所示：

其中/orderService表达了一个服务的概念，而下面的每个节点表示的是一个服务的实例。（orderService表示订单服务，而node表示的是每个有订单服务的服务器实例。）而每个节点也是需要和注册中心能进行通信的，因为只有这样，注册中心才能知道实时的正常服务。

3、master选举机制

思路：三个Batch Job启动以后，都去注册中心争抢去创建一个树的节点。（如/master）谁先创建成功，谁就是master(注册中心必须保证只能创建成功一次，其他请求就失败了。)其他两个batch job就对这个节点进行监控，如果这个节点被删除，就开始新一轮的争抢。

个人小结：
zookeeper可以用来实现分布式锁，同时也可以用来作为服务注册中心，其主要特点就是其数据结构是一个类似下面的树状图。可以使用sdk来增删改查各种节点。当时，只要你想象力够丰富，还可以做很多其他的事情。当然，zookeeper可以搭建集群来实现高可用。