ZooKeeper 的应用场景?

分析&回答


1、统一命名服务

统一命名服务的命名结构图如下所示:

  • 在分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同服务。
    • 类似于域名与ip之间对应关系,ip不容易记住,而域名容易记住。
    • 通过名称来获取资源或服务的地址,提供者等信息。
  • 按照层次结构组织服务/应用名称。
    • 可将服务名称以及地址信息写到ZooKeeper上,客户端通过ZooKeeper获取可用服务列表类。

2、配置管理

配置管理结构图如下所示:

  • 分布式环境下,配置文件管理和同步是一个常见问题。
    • 一个集群中,所有节点的配置信息是一致的,比如 Hadoop 集群。
    • 对配置文件修改后,希望能够快速同步到各个节点上。
  • 配置管理可交由ZooKeeper实现。
    • 可将配置信息写入ZooKeeper上的一个Znode。
    • 各个节点监听这个Znode。
    • 一旦Znode中的数据被修改,ZooKeeper将通知各个节点。

3、集群管理

集群管理结构图如下所示:

  • 分布式环境中,实时掌握每个节点的状态是必要的。
    • 可根据节点实时状态做出一些调整。
  • 可交由ZooKeeper实现。
    • 可将节点信息写入ZooKeeper上的一个Znode。
    • 监听这个Znode可获取它的实时状态变化。
  • 典型应用
    • Hbase中Master状态监控与选举。

4、分布式通知与协调

  • 分布式环境中,经常存在一个服务需要知道它所管理的子服务的状态。
    • NameNode需知道各个Datanode的状态。
    • JobTracker需知道各个TaskTracker的状态。
  • 心跳检测机制可通过ZooKeeper来实现。
  • 信息推送可由ZooKeeper来实现,ZooKeeper相当于一个发布/订阅系统。

5、分布式锁

处于不同节点上不同的服务,它们可能需要顺序的访问一些资源,这里需要一把分布式的锁。

分布式锁具有以下特性:

  1. ZooKeeper是强一致的。比如各个节点上运行一个ZooKeeper客户端,它们同时创建相同的Znode,但是只有一个客户端创建成功。
  2. 实现锁的独占性。创建Znode成功的那个客户端才能得到锁,其它客户端只能等待。当前客户端用完这个锁后,会删除这个Znode,其它客户端再尝试创建Znode,获取分布式锁。
  3. 控制锁的时序。各个客户端在某个Znode下创建临时Znode,这个类型必须为CreateMode.EPHEMERAL_SEQUENTIAL,这样该Znode可掌握全局访问时序。

6、分布式队列

分布式队列分为两种:

  • 当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
    • 一个job由多个task组成,只有所有任务完成后,job才运行完成。
    • 可为job创建一个/job目录,然后在该目录下,为每个完成的task创建一个临时的Znode,一旦临时节点数目达到task总数,则表明job运行完成。
  • 队列按照FIFO方式进行入队和出队操作,例如实现生产者和消费者模型。

反思&扩展


Zookeeper 中关于CAP理论是如何选择的?

  • ZooKeeper这种分布式协调系统,数据的一致性是最基本的要求,所以使用CP舍弃A。
  • Zookeeper在进行数据同步时,无法对外提供读写服务,不满足可用性A的要求。
  • 话外:Redis、HBase分布式存储系统也选择的 CP
  • 话外:传统数据库一般选择CA
  • 话外:分布式网站架构的一般选择AP

喵呜面试助手: 一站式解决面试问题,你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] -> 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

喵呜刷题

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值