Zookeeper在Linux容量规划中的定位与边界
- Zookeeper是分布式协调服务，数据以内存为主（DataTree），持久化由快照 snapshot与事务日志 transaction log承担；单节点数据上限为1MB，不适合存放大对象，大对象应放在外部存储，仅在ZK中保存指针。其存储与网络I/O主要发生在本地磁盘与节点间复制，因此容量规划要围绕磁盘空间、IOPS、内存、网络与JVM堆协同设计。
容量规划的核心方法与计算
- 磁盘容量（长期安全值）
- 核心公式：磁盘容量 ≈ 保留天数 ×（日均事务数 × 平均事务大小 + 快照增量）+ 安全余量
- 要点：
- 事务日志是顺序写，吞吐高但持续增长；快照是周期性全量，体积与数据规模相关。
- 开启自动清理：设置autopurge.snapRetainCount与autopurge.purgeInterval，避免历史文件无限累积。
- 建议将**dataDir（快照）与dataLogDir（事务日志）**分盘，避免互相抢占IOPS与空间。
- 内存与JVM
- ZK数据主要在内存，需为JVM堆预留充足空间（常见做法是物理内存的约1/3，视负载与GC策略调整），避免堆外内存压力与频繁GC。
- 通过JMX监控zk_approximate_data_size观察数据规模随时间的增长趋势，用于评估堆与机器规格是否需要升级。
- 连接与并发
- 通过maxClientCnxns限制单IP连接数，结合zk_num_alive_connections与zk_outstanding_requests识别连接风暴与请求堆积，进而规划文件描述符与内核网络参数（如ulimit -n、somaxconn）。
- 集群规模与容错
- 采用奇数节点（3/5/7），遵循多数存活原则：可用节点数 > 总节点数/2。节点越多写入需达成法定人数越多，写入延迟上升但可用性增强；读可横向扩展。
- 高可用验证
- 规划阶段即验证Leader选举时延与网络分区场景下的可用性边界，确保在实际Linux网络与存储条件下满足SLA。
容量估算示例与落地配置
- 假设：日均事务数1,000,000，平均事务大小1KB，快照保留7天，安全余量20%；设dataLogDir与dataDir分盘。
- 日志容量 ≈ 1,000,000 × 1KB × 7 = 7GB
- 快照容量（经验估算，实际以业务数据增长为准）≈ 2–5GB/天 × 7 ≈ 14–35GB
- 预留余量（20%）≈（7 + 14–35）× 20% ≈ 4.2–8.4GB
- 单节点建议磁盘容量 ≈ 25–50GB（按上限规划更安全）
- 关键配置建议（zoo.cfg）
- 分盘与保留策略
- dataDir=/data/zk；dataLogDir=/data/zk-log
- autopurge.snapRetainCount=5–7；autopurge.purgeInterval=24（小时）
- 连接与限流
- maxClientCnxns=500–2000（按并发与客户端规模调整）
- 网络与超时
- tickTime=2000；initLimit=10（5×tickTime）；syncLimit=5（2–5×tickTime）
- 监控与诊断
- 启用四字命令与JMX/Prometheus导出，便于容量趋势与异常告警。
监控告警与扩容策略
- 监控与阈值
- 磁盘使用率两级阈值：85% 告警、95% 危险；JMX关注zk_approximate_data_size、zk_num_alive_connections、zk_outstanding_requests；系统层面关注IOPS、await、%util。
- 日志关键字告警：“No space left on device”、快照/日志创建失败等，作为容量危机的早期信号。
- 扩容路径
- 水平扩容（加节点）：准备新节点→安装同版本ZK→配置server.x与唯一myid→先启动新节点→滚动重启旧节点→验证集群状态与数据同步→持续观察监控指标。
- 垂直扩容（升规格）：当数据规模或连接数持续增长且GC/延迟受影响时，优先升级磁盘（SSD/NVMe）与内存，再评估堆与GC策略。
- 风险与应急
- 严禁让磁盘写满：写满会导致只读/停服、事务日志不完整与恢复失败；日常保持清理任务与健康检查，异常时优先释放空间并回滚非关键数据。