架构 | 调优 - [zookeeper]

§0 实际使用的 zoo.cfg

### 时间配置
### 一个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 的日志应该怎么配
两种推荐配置方式

• 直接借鉴阿里云的参数：云上的微服务引擎对这几个参数做了通用的优化（但是想看到得买服务）
• 从实际运行上调整：
  • 预配置

  autopurge.snapRetainCount=3
  autopurge.purgeInterval=8
  

  • x 个小时后，计算磁盘占用
    • 假设此时有 n 个快照，每个快照的大小是 a
    • 则估算的快照占用为 [(n - 3) / x * 8 + 3] * a
    • 事务日志的计算同理
  • 故障恢复时间（待确定）

§1.3 tick 时间

tickTime=2000
initLimit=10
syncLimit=5

tickTime

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

initLimit

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

syncLimit

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