大数据 -27 ZooKeeper zoo.cfg 多节点分布式配置
点一下关注吧！！！非常感谢！！持续更新！！！
🚀 AI 篇持续更新中！（长期更新）
目前 2025 年 06 月 16 日更新到：AI 炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用 AI 工具指南！📐🤖
💻 Java 篇正式开启！（300 篇）
目前 2025 年 06 月 28 日更新到：Java-58 深入浅出 分布式服务 ACID 三阶段提交 3PC 对比 2PCMyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！
📊 大数据板块已完成多项干货更新（300 篇）：
包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！目前 2025 年 06 月 13 日更新到：大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解
章节内容
上一节我们完成了：
ZooKeeper 的简介
ZooKeeper 的下载安装
ZooKeeper 的单机配置和启动
背景介绍
这里是三台公网云服务器，每台 2C4G，搭建一个 Hadoop 的学习环境，供我学习。
2C4G 编号 h121
2C4G 编号 h122
2C2G 编号 h123
集群配置
上节我们是单机启动的，现在我们要启动三台：
H121
H122
H123
ZooKeeper 简介
核心特性
分布式一致性保证：
提供顺序一致性（所有更新请求按顺序执行）
原子性（更新要么成功要么失败）
单一系统镜像（无论连接到哪个服务器，客户端看到的数据视图都是一致的）
可靠性（一旦更新被应用，将保持到被下一次更新覆盖）
及时性（客户端在一定时间内能看到最新的数据）
数据模型：
本质上是一个分布式的小文件存储系统，采用类似 Unix 文件系统的树形层次结构（称为 ZNode Tree）
每个节点（ZNode）可以存储少量数据（默认上限 1MB）
节点分为持久节点（PERSISTENT）和临时节点（EPHEMERAL），后者在会话结束后自动删除
监控机制（Watcher）：
客户端可以注册监听特定节点的变化
当节点数据变更或子节点列表变化时会触发通知
采用一次触发机制，收到通知后需要重新注册
典型应用场景
统一命名服务：
如 Dubbo 服务注册中心，服务提供者将服务地址注册到 ZooKeeper
消费者从 ZooKeeper 获取可用的服务列表
示例：/dubbo/com.example.Service/providers 目录下存储服务提供者 URL
分布式配置管理：
如 Solr 集群配置同步，所有节点监听配置节点
配置变更时，管理员更新 ZooKeeper 上的配置数据
各节点收到变更通知后自动获取新配置
示例：/solr/configs/mycore 目录存储核心配置
分布式消息队列：
实现发布/订阅模式（Pub/Sub）
生产者创建顺序节点作为消息
消费者监听父节点获取新消息
示例：/queue/msg-0000000001，/queue/msg-0000000002
分布式锁：
实现互斥锁：多个客户端竞争创建同一个临时节点，成功创建的获得锁
实现共享锁：通过节点顺序特性实现读写锁
锁释放：会话结束自动删除临时节点或主动删除
集群管理：
监控集群节点存活状态（通过临时节点）
选举主节点（通过节点序号最小的成为 Master）
示例：/cluster/node1（临时节点）自动消失表示节点下线
工作原理
ZooKeeper 集群是一个高可用的分布式协调服务，其核心架构和运行机制如下：
集群组成与节点数量
典型部署包含 3 个、5 个或 7 个服务器节点（必须为奇数）
奇数数量便于选举时形成多数派（quorum），如：
3 节点集群可容忍 1 个节点故障（需要 2 个节点存活）
5 节点集群可容忍 2 个节点故障（需要 3 个节点存活）
每个节点都存储完整的数据副本
一致性协议
采用 ZAB（ZooKeeper Atomic Broadcast）协议，该协议包含两个主要阶段：a) 选举阶段：当 Leader 失效时，剩余节点通过投票选出新 Leaderb) 广播阶段：Leader 将事务请求以提案形式广播给所有 Follower
需要获得多数节点（N/2+1）的 ACK 才能提交事务
所有写操作都通过 Leader 处理，读操作可由任意节点响应
请求处理流程
客户端可以连接到集群中的任意节点
对于写请求：
接收节点会将请求转发给 Leader
Leader 生成事务提案并广播
获得多数确认后提交并响应客户端
对于读请求：
可直接由接收节点本地响应（可能读到稍旧数据）
可选 sync 操作确保读取最新数据
容错机制
故障检测通过心跳机制实现
Leader 失效时会自动触发新的选举
集群持续服务需要保持多数节点存活
数据持久化到磁盘，重启后自动恢复
典型应用场景
分布式锁服务
配置管理中心
命名服务
集群成员管理
选主服务
在实际生产环境中，通常会将 ZooKeeper 节点部署在不同的物理服务器或可用区，以避免单点故障。同时建议配置监控系统来跟踪节点健康状态和性能指标。
解压安装
查看上一节过程，对 ZooKeeper 下载和解压安装。你也可以使用之前封装好的 rsync-script 工具来完成 ZooKeeper 的分发。
环境变量
确保你的三台节点都配置对了环境变量
配置详解
tickTime：ZooKeeper 内部基本时间单位（毫秒），用于心跳和超时等
initLimit：Follower 启动并完成同步的最长 tick 数
syncLimit：Leader 和 Follower 之间请求和应答之间允许的最大 tick 数
dataDir：存储快照（snapshot）和事务日志（log）的目录
dataLogDir：可选：专门用于事务日志的目录，默认与 dataDir 相同（提高性能）
clientPort：客户端连接 ZooKeeper 的端口（默认 2181）
autopurge.snapRetainCount：自动清理快照时保留的快照数量
autopurge.purgeInterval：自动清理快照的周期（小时），默认 0 表示关闭
server.X：多节点配置：每个节点的 ID 和其通信端口
注意事项
单机模式只需 dataDir 和 clientPort 即可；
多机集群一定要配置 server.X 系列和每个节点的 myid；
tickTime 决定很多超时机制，设置过小会导致误判宕机，过大则影响故障恢复速度；
dataDir 和 dataLogDir 建议分离到不同磁盘以优化性能；
不建议设置 JVM 堆内存过大，避免 FullGC 阻塞心跳，推荐使用 G1 GC；
zk 配置
确保你的 zk 配置是正确的，且一致的
myid（重要）
这里我们单节点启动的时候，配置的是：
但是在其他节点上，我们需要写成 2、3 比如 h122 节点，应该写成：
比如 h123 节点，应该写成：
集群启动
h121 执行：zkServer.sh start
h122 执行：zkServer.sh start
h123 执行：zkServer.sh start
h121
h122
h123
查看日志
集群查看
h121
我们观察到 h121 是 Follower 追随者
h122
我们观察到 h122 是 Leader 领导者
h123
我们观察到 h123 是 Follower 追随者
版权声明: 本文为 InfoQ 作者【武子康】的原创文章。
原文链接:【http://xie.infoq.cn/article/59fbb2d756126ed23a70fba73】。文章转载请联系作者。
永远好奇 无限进步 2019-04-14 加入
Hi, I'm Zikang，好奇心驱动的探索者 | INTJ / INFJ 我热爱探索一切值得深究的事物。对技术、成长、效率、认知、人生有着持续的好奇心和行动力。 坚信「飞轮效应」，相信每一次微小的积累，终将带来深远的改变。
评论