架构 | 调优 - [zookeeper]

INDEX

- - [§0 实际使用的 zoo.cfg](#§0 实际使用的 zoo.cfg)
  - [§1 基础知识](#§1 基础知识)
  - - [§1.1 官网文档](#§1.1 官网文档)
    - [§1.2 日志相关配置](#§1.2 日志相关配置)
    - [§1.3 tick 时间](#§1.3 tick 时间)

§0 实际使用的 zoo.cfg

properties 复制代码

### 时间配置
### 一个tick（滴答）的毫秒数，时间单位，可以认为是心跳时间
tickTime=2000
### follower 连接 leader 并与之同步数据可以容忍的心跳数，影响选主成功率
### 如果 zookeeper 中数据量大，需要加大这个值
initLimit=10
### follower 与 leader 同步数据可以容忍的心跳数
syncLimit=5

### 数据存储路径配置
### 数据存储路径，快照和事务日志会保留在此路径下
dataDir=/data/zookeeper-data
### 用于重新制定事务日志存储路径，两种日志关联性较强，无特殊诉求不需要区分
#dataLogDir=/data/zookeeper-data/logs

### 自动清理
### 快照保留数，决定 dataDir 中保留最多几个最新的快照
### 并连带着在 dataLogDir 中保留这些快照的事务日志
autopurge.snapRetainCount=3
### 自动清理触发间隔时间，单位小时
autopurge.purgeInterval=8

### 客户端连接
### 客户端连接 zookeeper 所使用的端口
clientPort=2181
### zk server 可以容忍的最大客户端并发连接数
### 每个 ip 标识为一个 client，一个 socket 标识为一个链接
### 此配置的连接数耗尽时：too many connections from host - max is xxx
### 此参数可以用于预防 DoS 攻击
maxClientCnxns=60
### 是否启动内置管理器，不启动可以防止占用 8080 端口
admin.enableServer=false

### 集群配置
### 123 是 zookeeper 集群中各个 server 的序号，要和个子的 myid 保持一致
### 第一个端口是 follower 与 leader 同步信息的端口
### 第二个端口是 leader 宕机后选主用的端口
server.1=192.168.3.76:2888:3888
server.2=192.168.3.77:2888:3888
server.3=192.168.3.78:2888:3888
### 允许集群监听来自所有可用 ip 的连接
### 如果不配此参数，需要将 server.x 中对应当前节点的 ip 置换为 0.0.0.0
### 如 myid=1 时，server.1=0.0.0.0:2888:3888
### 因机器具有公网 ip 时，对 3888 的端口监听失效
### 详见 https://stackoverflow.com/questions/30940981/
quorumListenOnAllIPs=true

§1 基础知识

§1.1 官网文档

3.8.4 版本的传送门
 配置的传送门

§1.2 日志相关配置

zookeeper 的日志说的是什么

zookeeper 的文件系统是一个内存数据库，日志系统同时是其持久化方式

zookeeper 中一共有三种日志

zookeeper 本身的日志（zookeeper-root-server.out）
快照日志（snapshot）：内存数据库的快照，即文件系统的快照
事务日志（transaction log）
宕机后，zk会从最近的snapshot 恢复，然后按事务日志重做，以快速恢复到工作状态

zookeeper 日志相关的参数主要有什么

下面 4 个配置直接控制快照与事务日志的生成，日志会直接占用磁盘

配置不合理时，可能导致触发自动清理前日志文件就把磁盘打满了，引发故障

autopurge.snapRetainCount：自动清理日志后，保留几个最新的 snapshot 及其相关的事务日志，默认 3
这个参数同时限制两种日志，两种日志关联性较强，从这个角度看 dataLogDir 没有特殊诉求没必要配置
autopurge.purgeInterval：自动清理触发间隔，单位小时，默认 1
snapCount：事务日志最大事务数，默认 10w
距离上次 snapshot 后，事务条数累计达到 snapCount/2 之后，都可能触发一次 snapshot
zookeeper 启动时，会在 snapCount/2 ~ snapCount 之间随机出一个具体值
当达到这个值时，触发快照，下面的 snapSizeLimitInKb 同理
snapSizeLimitInKb：事务日志最大千字节数，默认 4G
距离上次 snapshot 后，事务日志大小达到 snapSizeLimitInKb/2 之后，都可能触发一次 snapshot

这几个参数有什么影响

如果降低 snapshot 频率过低，不会占用太多磁盘，但从磁盘恢复节点的状态就会过长

如果增加 snapshot 频率过高，会占用大量磁盘，但从磁盘恢复节点速度回提高

如果自动清理频率过低，会增加触发清理前打满磁盘的风险

如果自动清理频率过高，可能导致无端占用系统资源

zookeeper 的日志应该怎么配

两种推荐配置方式

直接借鉴阿里云的参数：云上的微服务引擎对这几个参数做了通用的优化（但是想看到得买服务）
从实际运行上调整：
- 预配置
properties 复制代码
```
autopurge.snapRetainCount=3
autopurge.purgeInterval=8
```
- x 个小时后，计算磁盘占用
  - 假设此时有 n 个快照，每个快照的大小是 a
  - 则估算的快照占用为 [(n - 3) / x * 8 + 3] * a
  - 事务日志的计算同理
- 故障恢复时间（待确定）

§1.3 tick 时间

properties 复制代码

tickTime=2000
initLimit=10
syncLimit=5

tickTime

zookeeper 使用 ticktime 作为基本时间单元
tickTime 同时作为心跳时间
时间限制的相关配置大多是基于此时间单元进行的

initLimit

follower 连接 leader 并与之同步数据可以容忍的心跳数
此配置配置过小会影响选主成功率
因为此时间限制还包括了同步数据的部分，所以当集群中数据量较大时，也应该对应的加大此配置

syncLimit

follower 与 leader 同步数据可以容忍的心跳数