ZooKeeper基本原理
ZooKeeper结构
ZooKeeper集群中的节点分为三种角色:Leader、Follower和Observer,其结构和相互关系如图1所示。通常来说,需要在集群中配置奇数个(2N+1)ZooKeeper服务,至少(N+1)个投票才能成功的执行写操作。
名称 |
描述 |
---|---|
Leader |
在ZooKeeper集群中只有一个节点作为集群的Leader,由各Follower通过ZooKeeper Atomic Broadcast(ZAB)协议选举产生,主要负责接收和协调所有写请求,并把写入的信息同步到Follower和Observer。 |
Follower |
Follower的功能有两个:
|
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原理
- 写请求
- Follower或Observer接收到写请求后,转发给Leader。
- Leader协调各Follower,通过投票机制决定是否接受该写请求。
- 如果超过半数以上的Leader、Follower节点返回写入成功,那么Leader提交该请求并返回成功,否则返回失败。
- Follower或Observer返回写请求处理结果。
- 只读请求
客户端直接向Leader、Follower或Observer读取数据。
ZooKeeper常见规格
ZooKeeper服务的常见系统规格如ZooKeeper常见规格所示。
指标名称 |
规格 |
说明 |
---|---|---|
单集群ZooKeeper最大实例数 |
9 |
ZooKeeper最大实例数 |
每个ZooKeeper实例,单个IP最大连接数 |
2000 |
- |
每个ZooKeeper实例,最大连接总数 |
20000 |
- |
默认参数情况下,最大ZNode数 |
2000000 |
ZNode数量过大会对服务稳定性造成影响,降低组件读写性能。 一般业务场景下建议ZNode数量在200w以内,如果集群仅部署了ClickHouse,ZNode数量可以扩大到600w以内。 |
单个ZNode大小 |
4MB |
- |