ZooKeeper 01 - 什么是 ZooKeeper - 瘦风 - 博客园
首页
新闻
博问
专区
闪存
班级
我的博客
我的园子
账号设置
简洁模式 ...
退出登录
注册
登录
瘦风的南墙
瘦风
Stay Hungry, Stay Foolish.
博客园
首页
新随笔
联系
管理
订阅
ZooKeeper 01 - 什么是 ZooKeeper
ZooKeeper 可以理解成管理项目中配置文件的服务 —— 通过集群，提供一致性协调服务，可以很大程度上减少维护的代价，提高开发效率，本篇简单介绍了 ZooKeeper 的来历及主要功能，欢迎交流。
目录1 - 什么是 ZooKeeper2 - ZooKeeper 的功能2.1 配置管理2.2 命名服务2.3 分布式锁2.4 集群管理版权声明
首发于 2018-08-31，修改于 2021-12-05。
1 - 什么是 ZooKeeper
ZooKeeper 直译就是动物园管理员，它是用来管 Hadoop(大象)、Hive(蜜蜂)、Pig(小猪) 等的管理员（这些都是 Apache 软件基金组织下大数据方面的技术框架），Apache HBase、Kafka、Pulsar、Solr 的分布式集群都用到了ZooKeeper。
(1) 百度百科中的说明：
ZooKeeper 是一个高可用、分布式的程序协调服务，是 Google Chubby 的一个开源的实现，是 Hadoop 和 HBase 的重要组件。
它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、Group 分组服务等。
ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
(2) ZooKeeper 的基本运转流程:
① 选举 Leader；
② 同步数据；
③ 选举 Leader 过程中算法有很多，但要达到的选举标准是一致的；
④ Leader 要具有最高的执行 ID，类似 root 权限；
⑤ 集群中大多数的机器得到响应并接受选出的 Leader。
2 - ZooKeeper 的功能
2.1 配置管理
项目开发中大多会涉及到各种配置信息，比如 JDBC 的连接信息等。一般将这些信息配置到特定的文件中，在代码中引入相关配置文件即可。
—— 这是单服务器应用中常用的做法。当应用很大、配置文件很多，尤其是在分布式项目中，多台服务器的配置需要保持一致，而如果配置信息会被频繁地修改，这个时候还使用配置文件就不是个好主意了。
—— 你总不能手动逐个修改吧？ 不仅重复性劳动太多，而且出错的可能性更大，后期维护成本太大。
这种情况下往往需要寻找 一种集中管理配置的方法 —— 在这个集中的地方修改了配置，所有对该配置有依赖的服务都可以获得变更。
需要考虑的是，由于多台服务器上的项目都依赖了这个配置，为了应用的可靠运行，需要这个集中提供配置服务的应用具备非常高的可靠性。
基于上述分析，我们可以通过集群来提供配置服务，保证系统的可靠性。此时遗留的问题是，如何保证配置在集群中的一致性呢？
为了提供这种一致性，前辈们提出了一致性协议，实现此协议的服务就有 ZooKeeper —— 它使用 Zab 这种一致性协议来保证一致性。
应用场景：
○ HBase 中，客户端就是连接一个ZooKeeper，它获得 HBase 集群的必要配置信息，然后才可以进一步操作。
○ 开源消息队列 Kafka 中，使用 ZooKeeper 来维护 broker 的信息。
○ Alibaba 开源的 SOA 框架 Dubbo 中广泛使用 ZooKeeper 管理配置信息，实现服务治理。
2.2 命名服务
场景：为了通过网络访问一个系统，我们需要知道对方的 IP 地址，但由于 IP 地址是一串数字，难以记忆，对用户并不友好。这时人们想出通过域名来访问指定的 IP 地址。
但计算机并不能识别域名。为了解决这一问题，设计者们提出了在每台电脑中都存储一份“域名到 IP 地址的映射”的方案。问题又来了，如果域名对应的IP地址发生了变化，又该如何映射呢？
前辈们又设计了 DNS(Domain Name System，域名系统)。我们只需要先访问一个所有机器都知道的（known）的节点，DNS 通过该节点告诉我们当前访问的域名对应的 IP 地址是什么。也就是 DNS 提供统一的访问接口。
在应用开发中也会存在这类问题，特别是应用中存在大量服务时，如果我们将服务的地址保存在本地，其他用户是不好获取这些地址并访问的。但是如果我们为用户提供统一的入口，在本地对各种用户请求作相应的映射处理，就可以解决此类问题。
2.3 分布式锁
ZooKeeper 是一个分布式协调服务，我们可以利用 ZooKeeper 来协调多个分布式进程之间的活动。
比如在一个分布式环境中，为提高系统的可靠性，集群中的每台服务器都部署了相同的服务。
这些相同的服务都要执行相同的任务，为了保证数据的一致性，集群之间就要互相协调，常规的编程方案解决协调问题是非常复杂繁琐的。
通常的做法是：使用分布式锁，在某个时刻只有一个服务在工作，当这台服务出了问题锁就立即释放，并 fail-over（故障恢复）到其他服务。这种设计被称作叫 Leader Election（leader选举），比如 HBase 的 Master 就采用了这种机制。
注意：分布式锁与进程锁是有区别的，使用时要更加谨慎。
2.4 集群管理
在分布式集群应用中，存在诸如软硬件故障、断电、网络等问题，存在节点出入现象，即新节点加入集群，老节点退出集群。出现这些情况时，集群中其他节点要能感知到这种变化，然后根据这种变化做出对应的决策。
【应用场景】
○ 在分布式存储系统中，有一个中央控制节点负责存储的分配，有新的存储节点加入进来时，需要根据集群状态来动态分配存储节点，这需要实时感知集群的状态。
○ 在分布式 SOA 架构中，服务由某一集群提供，当消费者访问某个服务时，需要采用某种机制发现集群中有哪些节点可以提供该服务（这也称之为服务发现，比如 Alibaba 开源的 Dubbo 就采用了 ZooKeeper 作为服务发现的底层机制）。
○ Kafka 中，通过 ZooKeeper 对 Consumer 的上下线进行管理。
版权声明
作者：瘦风(https://healchow.com)
出处：博客园-瘦风的南墙(https://www.cnblogs.com/shoufeng)
感谢阅读，公众号 「瘦风的南墙」 ，手机端阅读更佳，还有其他福利和心得输出，欢迎扫码关注🤝
本文版权归博主所有，欢迎转载，但 [必须在页面明显位置标明原文链接]，否则博主保留追究相关人士法律责任的权利。
posted @
2018-08-31 23:58
瘦风
阅读(1507)
评论(0)
编辑
收藏
举报
刷新评论刷新页面返回顶部
Copyright 2022 瘦风
Powered by .NET 7.0 on Kubernetes