Zookeeper应用场景

  1. 数据发布/订阅
    • 数据发布/订阅,就是一方吧数据发布出来,另一方通过某种手段就可以得到这些数据
      通常数据订阅有两种方式:推模式,拉模式,退模式一般是服务器主动向客户端推送信息,拉模式是客户端主动去服务器获取数据(通常是采用定时轮询的方式)
    • ZK采用两种那个方式相结合
      发布者将数据发布到ZK集群节点上,订阅者通过一定的方式告诉服务器,我对那个节点的数据感兴趣,那服务器在这些节点的数据发生变化时,就通知客户端,客户端得到通知后可以去服务器获取数据信息
  2. 负载均衡
    数据库启动的时候再zk上对应节点,不可用时候自动删除,client 先从zk得到所有节点的信息,通过随机算法每次连接一个
    • 首先DB在启动的时候先把自己在ZK上注册成一个临时节点,ZK的节点有两种,一种是永久节点,一种是临时节点,临时节点在服务器出现问题的时候,节点会自动的从ZK上删除,那么这样zk上的服务器列表就是最新的可用列表
    • 客户端在需要读写数据库的时候首先它去zk得到所有可用的Db连接信息(一个列表)
    • 客户端随机选择一个与之建立连接
    • 当客户端发现连接不可用的时候可再次从ZK上获取可用的DB连接信息,当然也可以在刚获取的那个列表里移除掉不可用的连接后再随机选择一个db与之连接
  3. 命名服务
    提供名称的服务,例如数据库表格ID,一般用的比较多的有两种Id,一种是自动增长的ID,一种是UUID,两个ID各自都有缺陷,自动增长的ID局限在单库单表中使用,不能在分布式中使用,UUID可以在分布式中使用但是由于ID没有规律难于理解,我们可以借用ZK来生成一个顺序增长,可以在集群环境下使用的,命名易于理解的ID
  4. 分布式协调/通知
    心跳检测
    分布式系统中,我们常常需要知道某个机器是否可用,传统的开发中,可以用个ping某个主机来实现,ping得通说明对面是可用的,相反是不可用的,zk中我们让所有的机器都注册一个临时节点,我们判断一个机器是否可用,我们只需要判断这个节点在ZK中是否存在就可以了,不需要直接去连接需要检查的机器,降低系统的复杂度