大数据系统架构实践（一）：Zookeeper集群部署

---

随着微服务架构和分布式系统的快速发展，系统中各个服务之间的协调和状态管理成为架构设计的重要一环。Zookeeper 作为 Apache 生态下的核心组件，提供了高可用的分布式协调服务，在 Hadoop、Kafka、HBase 等大数据平台中都扮演着不可替代的角色。

在本系列中，我们将围绕 Zookeeper 在大数据系统中的作用与部署实践展开介绍。本篇作为第一篇，将聚焦于 Zookeeper 的核心概念、常见应用场景及基础部署方式，为后续深入理解其在分布式架构中的地位打下基础。

一、Zookeeper简介

Zookeeper 是一个开源的分布式协调服务，主要用于维护配置信息、命名服务、分布式同步和集群管理。它的设计初衷是为分布式系统提供一致性保障，并简化复杂的协调任务。
Zookeeper 的 核心特性 包括：

• 强一致性：所有客户端都能读取到最新的数据状态
• 原子性：一次操作要么成功，要么失败
• 顺序性：所有更新按照顺序执行
• 高可用性：通过集群部署实现故障容错与快速恢复

Zookeeper 使用类 Unix 文件系统的层级数据模型，节点称为 ZNode 。每个 ZNode 都可以存储数据，并可具有子节点。常见节点类型：

• 持久节点（Persistent）
• 临时节点（Ephemeral）
• 顺序节点（Sequential）

这种结构为服务注册、分布式锁、选举等提供了基础。

二、部署前准备

Zookeeper 是一个典型的强一致性系统，采用的是 ZAB（Zookeeper Atomic Broadcast）协议，其核心思想是多数派写成功即认为成功。因此：

• Zookeeper 集群必须部署在奇数台服务器上（3、5、7…）
• 最小推荐部署为 3 台节点，此时允许容忍 1 台节点宕机仍可继续提供服务
• 如果使用 2 台节点，当 1 台挂掉时，剩下的无法形成多数，整个集群将无法写入

因此，3 节点集群在资源和高可用性之间提供了合理平衡，是生产环境中最常见的部署方式。
多数派投票原则：n = 2f + 1，f 是允许容忍的故障节点数量。3 台机器允许 1 台故障，5 台允许 2 台故障。

✅ 三台服务器的配置与角色

节点名称	主机名	ip地址	说明
master	master	192.168.100.1	集群节点之一，参与选举
slave1	slave1	192.168.100.2	集群节点之一，参与选举
slave2	slave2	192.168.100.3	集群节点之一，参与选举

✅ JDK 依赖环境
Zookeeper 是用 Java 编写的，运行前请确保已安装 JDK 1.8 或以上版本

三、部署Zookeeper集群

1. 下载并解压安装包

# 下载地址（以3.4.10版本为例）
https://archive.apache.org/dist/zookeeper/# 解压移动
tar xf zookeeper-3.4.10.tar.gz
mv zookeeper-3.4.10 /usr/local/zookeeper

2. 配置zoo.cfg

cat > /usr/local/zookeeper/conf/zoo.cfg <<-EOF
tickTime=10000  # 心跳时间，ms
dataDir=/usr/local/zookeeper/data  # 数据存储路径
clientPort=2181  # 端口号
initLimit=5  # Follower初始化连接Leader的超时时间限制
syncLimit=2  # Follower与Leader之间同步响应的最大延迟时间
server.1=master:2888:3888  # server.x 对应的是 myid 值
server.2=slave1:2888:3888 
server.3=slave2:2888:3888
maxClientCnxns=1000  # 允许的最大连接数
maxSessionTimeout=300000  # 会话的最大超时时间，ms
EOF

3. 设置日志目录

编辑日志配置文件，指定日志输出目录

mkdir -p /usr/local/zookeeper/logsvim /usr/local/zookeeper/conf/log4j.properties
# 修改如下变量：
# zookeeper.log.dir=/usr/local/zookeeper/logs
# zookeeper.tracelog.dir=/usr/local/zookeeper/logsvim /usr/local/zookeeper/bin/zkEnv.sh
# 设置 ZOO_LOG_DIR=/usr/local/zookeeper/logs

4. 集群编号

每台节点的 myid 是其在 zoo.cfg 中的 server ID，并将目录同步至其他节点

mkdir -p /usr/local/zookeeper/data
echo "3" > /usr/local/zookeeper/data/myid
scp -rp /usr/local/zookeeper root@slave2:/usr/local/  &>/dev/null
echo "2" > /usr/local/zookeeper/data/myid
scp -rp /usr/local/zookeeper root@slave1:/usr/local/  &>/dev/null
echo "1" > /usr/local/zookeeper/data/myid

5. 启动zookeeper集群

# master
/usr/local/zookeeper/bin/zkServer.sh start
# slave1
ssh slave1 "/usr/local/zookeeper/bin/zkServer.sh start"
# slave2
ssh slave2 "/usr/local/zookeeper/bin/zkServer.sh start"

5. 验证集群状态

# 检查端口是否监听
netstat -tnlp | grep 2181
# 查看进程是否正常
ps -ef | grep QuorumPeerMain
# 查看集群状态
/usr/local/zookeeper/bin/zkServer.sh status

---

总结

🚀 本文介绍了 Zookeeper 的核心概念与应用场景，并基于 3 台服务器完成了 Zookeeper 集群的部署与配置。通过设置 zoo.cfg 配置文件、myid 标识、日志目录和启动脚本，我们搭建了一个基本的高可用协调服务，为后续大数据系统提供稳定的元数据和状态支持。
⚠️ 值得注意的是，Zookeeper 的 Leader 是通过选举产生的，部署过程中不应人为指定具体节点为 Leader 或 Follower，所有节点都是平等参与选举的角色。
📌 当前部署方式适用于 Hadoop、Kafka、HBase 等组件依赖的协调服务环境，是分布式系统架构的基础支撑。
✅ 下一篇文章中，我们将继续构建大数据系统核心组件 —— Hadoop 分布式文件系统（HDFS）与资源调度框架（YARN），并实现其与 Zookeeper 的集成与联动，逐步完善整个大数据平台的底座架构。