更新时间:2024-08-03 GMT+08:00

ZooKeeper基本原理

ZooKeeper简介

ZooKeeper是一个分布式、高可用性的协调服务。在大数据产品中主要提供两个功能:

  • 帮助系统避免单点故障,建立可靠的应用程序。
  • 提供分布式协作服务和维护配置信息。

ZooKeeper结构

ZooKeeper集群中的节点分为三种角色:Leader、Follower和Observer,其结构和相互关系如图1所示。通常来说,需要在集群中配置奇数个(2N+1)ZooKeeper服务,至少(N+1)个投票才能成功的执行写操作。

图1 ZooKeeper结构

图1中各部分的功能说明如表1所示。

表1 结构图说明

名称

描述

Leader

在ZooKeeper集群中只有一个节点作为集群的Leader,由各Follower通过ZooKeeper Atomic Broadcast(ZAB)协议选举产生,主要负责接收和协调所有写请求,并把写入的信息同步到Follower和Observer。

Follower

Follower的功能有两个:

  • 每个Follower都作为Leader的储备,当Leader故障时重新选举Leader,避免单点故障。
  • 处理读请求,并配合Leader一起进行写请求处理。

Observer

Observer不参与选举和写请求的投票,只负责处理读请求、并向Leader转发写请求,避免系统处理能力浪费。

Client

ZooKeeper集群的客户端,对ZooKeeper集群进行读写操作。例如HBase可以作为ZooKeeper集群的客户端,利用ZooKeeper集群的仲裁功能,控制其HMaster的“Active”和“Standby”状态。

如果集群启用了安全服务,在连接ZooKeeper时需要进行身份认证,认证方式有以下两种:

  • keytab方式:需要从MRS集群管理员处获取一个“人机”用户,用于登录MRS平台并通过认证,并且获取到该用户的keytab文件。
  • 票据方式:从MRS集群管理员处获取一个“人机”用户,用于后续的安全登录,开启Kerberos服务的renewable和forwardable开关并且设置票据刷新周期,开启成功后重启kerberos及相关组件。
    • 默认情况下,用户的密码有效期是90天,所以获取的keytab文件的有效期是90天。
    • Kerberos服务的renewable、forwardable开关和票据刷新周期的设置在Kerberos服务的配置页面的“系统”标签下,票据刷新周期的修改可以根据实际情况修改“kdc_renew_lifetime”和“kdc_max_renewable_life”的值。

ZooKeeper原理

  • 写请求
    1. Follower或Observer接收到写请求后,转发给Leader。
    2. Leader协调各Follower,通过投票机制决定是否接受该写请求。
    3. 如果超过半数以上的Leader、Follower节点返回写入成功,那么Leader提交该请求并返回成功,否则返回失败。
    4. Follower或Observer返回写请求处理结果。
  • 只读请求

    客户端直接向Leader、Follower或Observer读取数据。

ZooKeeper常见规格

ZooKeeper服务的常见系统规格如ZooKeeper常见规格所示。

表2 ZooKeeper常见规格

指标名称

规格

说明

单集群ZooKeeper最大实例数

9

ZooKeeper最大实例数

每个ZooKeeper实例,单个IP最大连接数

2000

-

每个ZooKeeper实例,最大连接总数

20000

-

默认参数情况下,最大ZNode数

2000000

ZNode数量过大会对服务稳定性造成影响,降低组件读写性能。

一般业务场景下建议ZNode数量在200w以内,如果集群仅部署了ClickHouse,ZNode数量可以扩大到600w以内。

单个ZNode大小

4MB

-