zookeeper部署

ZooKeeper 部署指南：从本地测试到生产集群

ZooKeeper 的部署方式需根据场景选择：本地部署适合开发测试，集群部署则是生产环境的必备方案，以保证高可用和容错性。以下详细介绍两种部署方式的配置与操作细节。

本地单机部署（开发测试用）

本地部署仅需单节点，步骤简单，适合调试分布式协调逻辑（如分布式锁、配置同步）。

环境准备

• 依赖：JDK 1.8+（ZooKeeper 运行在 JVM 上）；
• 下载安装：从 Apache 官网 下载稳定版本（如 3.8.0），解压至本地目录（如 /opt/zookeeper）。

核心配置（conf/zoo.cfg）

ZooKeeper 启动时需加载配置文件，默认读取 conf/zoo.cfg，核心参数如下：

# Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，每隔 tickTime时间就会发送一个心跳，单位毫秒，每次心跳2000毫秒
tickTime=2000

# 初始通信时限 集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限    总的时间长度为 initLimit*tickTime
initLimit=10


# 同步通信时限，集群中Leader与Follower之间的最大响应时间单位，假如响应超过该时间，Leader认为Follwer死掉，从服务器列表中删除Follwer   总的长度为 syncLimit*tickTime
syncLimit=5

# 数据存储目录：存放快照数据（内存数据的持久化快照）
dataDir=/opt/data/zookeeper/zkData

# 客户端连接端口（默认 2181）
clientPort=2181

# 默认使用的是dataDir配置，用于存储事务日志文件，默认会将事务日志文件和快照数据存储在同一个目录下，建议分开
# 事务日志记录对于磁盘性能要求比较高，直接决定了zookeeper在处理事务请求时的吞吐
dataLogDir=/opt/data/zookeeper/zkLog

# 自动清理快照和日志（可选）
# 保留最近 3 个快照，每 1 小时清理一次
autopurge.snapRetainCount=3
autopurge.purgeInterval=1

注意：需手动创建 dataDir 和 dataLogDir 目录（如 mkdir -p /opt/data/zookeeper/{zkData,zkLog}）。

启动与验证

• 启动服务：

  # 后台启动
  ./bin/zkServer.sh start
  
  # 前台启动（方便查看日志，适合调试）
  ./bin/zkServer.sh start-foreground

• 验证启动状态：

  ./bin/zkServer.sh status
  # 成功输出示例：Mode: standalone（单机模式）

• 连接客户端：

  ./bin/zkCli.sh -server localhost:2181
  # 连接成功后可执行 Zookeeper 命令（如 create /test "hello"、get /test）

• 停止服务：

  ./bin/zkServer.sh stop

集群分布式部署（生产环境用）

生产环境需部署 ZooKeeper 集群（至少 3 节点），利用 “过半存活” 机制保证高可用，避免单点故障。

集群规划

• 节点数量：推荐奇数（3、5、7 节点），满足 “过半存活” 原则（如 3 节点集群允许 1 节点故障）；
• 服务器配置：每节点建议 2C4G 以上，磁盘选用 SSD（提升事务日志写入性能）；
• 网络：节点间内网通信，保证低延迟（建议 < 10ms）。

示例集群（3 节点）：

节点 IP	主机名	客户端端口	集群通信端口	选举端口
192.168.1.101	zoo1	2181	2888	3888
192.168.1.102	zoo2	2181	2888	3888
192.168.1.103	zoo3	2181	2888	3888

集群配置（conf/zoo.cfg）

所有节点的配置基本一致，核心差异在于 server.id 配置和 myid 文件。

# 基础配置（与单机相同）
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/logs
clientPort=2181
# 分布式部署特有的
# server.id=host:port:port
# id是在myid文件中填写的id编号，在集群中要唯一，需要在dataDir下创建一个myid的文件，内容为该节点的编号
# host为服务器地址
# 第一个port指的是该服务器与Leader通信的端口
# 第二个port指的是如果leader挂掉，用来执行选举时服务器相互通信的端口
# 集群节点配置：server.id=host:通信端口:选举端口
# id：节点唯一标识（1~255），需与 myid 文件一致
# 通信端口（2888）：Follower 与 Leader 同步数据的端口
# 选举端口（3888）：节点间选举 Leader 时使用的端口
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888

注意：需在 /etc/hosts 中配置主机名与 IP 的映射（如 192.168.1.101 zoo1），或直接使用 IP 替代主机名。

配置节点唯一标识（myid 文件）

每个节点需在 dataDir 目录下创建 myid 文件，内容为该节点的 id（与 zoo.cfg 中 server.id 的 id 一致）：

• zoo1 节点：

  echo 1 > /var/lib/zookeeper/data/myid

• zoo2 节点：

  echo 2 > /var/lib/zookeeper/data/myid

• zoo3 节点：

  echo 3 > /var/lib/zookeeper/data/myid

启动集群与验证

• 逐个启动节点：

  # 在每个节点执行
  ./bin/zkServer.sh start

• 验证集群状态：
  在任一节点执行 ./bin/zkServer.sh status，查看节点角色：

  • Leader：集群主节点（处理写请求，同步数据到 Follower）；
  • Follower：从节点（处理读请求，参与 Leader 选举）。
    示例输出（zoo1 为 Leader）：

  Mode: leader

  其他节点输出：

  Mode: follower

• 测试故障容错：
  手动停止 Leader 节点（如 ./bin/zkServer.sh stop），观察其他节点是否重新选举新 Leader（约 10~30 秒），验证集群仍能正常提供服务。

集群运维建议

• 日志管理：定期清理 dataLogDir 和 dataDir 下的旧日志（可通过 autopurge 配置自动清理）；
• 监控告警：通过 Prometheus + Grafana 监控节点状态（如 zk_server_num_alive_connections、zk_server_leader），设置节点宕机、磁盘满等告警；
• 滚动升级：升级集群时，先停 Follower 节点，升级后重启，最后升级 Leader（避免集群不可用）；
• 备份恢复：定期备份 dataDir 下的快照数据，用于灾难恢复。

部署常见问题与解决方案

1. 启动失败，日志报 “Address already in use”
   • 原因：clientPort、2888 或 3888 端口被占用；
   • 解决：通过 netstat -tunlp | grep 端口号 查找占用进程并杀死，或修改配置文件更换端口。
2. 集群节点无法选举 Leader
   • 原因：myid 与 server.id 不匹配，或节点间网络不通（防火墙拦截 2888/3888 端口）；
   • 解决：检查 myid 文件内容，关闭防火墙（或开放端口），确保节点间能 ping 通且端口可访问。
3. 客户端连接超时
   • 原因：clientPort 未开放，或集群未正常启动；
   • 解决：检查节点状态（zkServer.sh status），确认防火墙开放 2181 端口。