当前位置: 首页 > news >正文

大数据学习(88)-zookeeper实现的高可用(HA)

🍋🍋大数据学习🍋🍋

🔥系列专栏: 👑哲学语录: 用力所能及,改变世界。
💖如果觉得博主的文章还不错的话,请点赞👍+收藏⭐️+留言📝支持一下博主哦🤞


ZooKeeper 实现高可用的能力详解

ZooKeeper 不仅是实现分布式系统高可用(HA)的关键工具,其自身也通过特定架构设计实现了高可用特性。

一、ZooKeeper 自身的高可用实现

1. 集群架构设计

典型部署:由3/5/7个节点组成的 ZooKeeper Ensemble

[Client] → [Leader]
            ↑
[Follower] ←→ [Follower]
 

高可用保障

  • 自动Leader选举:基于ZAB协议(ZooKeeper Atomic Broadcast)

  • 数据一致性:所有写操作通过Leader协调,保证顺序一致性

  • 读操作扩展:Follower可直接处理读请求

2. 容错能力

集群规模可容忍故障节点数最少存活节点要求
3节点12
5节点23
7节点34

选举过程示例

  1. 节点启动后进入LOOKING状态

  2. 交换投票信息(包含zxid和serverid)

  3. 获得多数派投票的节点成为Leader

  4. 其余节点成为Follower并同步数据

3. 数据持久化

  • 事务日志:所有写操作先写磁盘日志(顺序IO)

  • 内存快照:定期生成snapshot加速恢复

  • WAL机制:Write-Ahead Logging保证数据不丢失

二、ZooKeeper 如何为其他系统提供高可用

1. 核心功能支持

功能高可用实现案例
分布式锁防止多节点同时操作关键资源
服务注册与发现实时感知服务节点存活状态
配置管理集群所有节点配置即时同步
Leader选举确定唯一活跃节点(如HDFS NameNode)

2. 典型集成方案

(1) HDFS NameNode HA
graph LR
    ActiveNN[Active NameNode] -->|写入| JN[JournalNodes]
    StandbyNN[Standby NameNode] -->|读取| JN
    ZKFC[ZKFC] -->|监控| ZK[ZooKeeper]
    ZKFC --> ActiveNN
    ZKFC --> StandbyNN

故障转移流程

  1. ZKFC检测到Active NN心跳超时

  2. 在ZK创建临时节点尝试接管

  3. 获得锁的Standby NN切换为Active

  4. 通过JournalNodes同步最新状态

(2) Kafka Controller选举
  • 每个Broker在ZK注册临时节点

  • 第一个成功创建/controller节点的Broker成为Controller

  • Controller故障时自动重新选举

三、ZooKeeper高可用配置实践

1. 关键配置参数

zoo.cfg

# 集群节点配置
server.1=zk1:2888:3888  # 2888用于Leader通信,3888用于选举
server.2=zk2:2888:3888
server.3=zk3:2888:3888

# 会话超时控制
tickTime=2000  # 基础时间单元(ms)
initLimit=10   # 初始化连接最长等待tick数
syncLimit=5    # 心跳请求最长等待tick数

# 数据目录
dataDir=/var/lib/zookeeper
dataLogDir=/var/log/zookeeper  # 事务日志单独目录

2. 监控指标

关键监控项

  • zk_avg_latency:平均请求处理时间(应<50ms)

  • zk_outstanding_requests:排队请求数(应<10)

  • zk_followers:正常Follower数量

  • zk_znode_count:znode总数监控

四字命令检查

echo stat | nc localhost 2181  # 查看状态
echo mntr | nc localhost 2181  # 监控指标

四、ZooKeeper高可用的局限性

  1. 写性能瓶颈

    • 所有写操作必须通过Leader

    • 集群规模扩大时写吞吐量不会增加

  2. 脑裂风险

    • 网络分区可能导致双Leader

    • 需要通过quorum配置预防(N/2+1)

  3. 会话风暴

    • 大量客户端重连可能导致集群过载

    • 解决方案:客户端采用指数退避重试

        ZooKeeper通过其分布式共识算法和集群架构,既能保障自身服务的高可用,又能作为基础设施为其他分布式系统提供可靠的协调服务。正确配置和使用时,ZooKeeper集群可以实现99.99%以上的可用性。

这里值得说明的是:初始 LOOKING 状态的定义

        在 ZooKeeper 集群中,LOOKING 是服务器节点启动或发现无 Leader 时进入的特殊状态,表示该节点正在主动寻找或参与 Leader 选举。这是 ZooKeeper 实现高可用的核心机制之一。

当当前的Leader崩溃

  1. Follower检测到Leader心跳超时(默认2*tickTime)

  2. 所有Follower转入LOOKING状态

  3. 启动新一轮选举,选择zxid最大的节点

  4. 新Leader产生后同步数据

相关文章:

  • 【JSqlParser】Java使用JSqlParser解析SQL语句总结
  • 垃圾回收学习
  • “thrust“ has no member “device“
  • 视觉Transformer架构的前沿优化技术与高效部署
  • Linux 驱动总线中的 ACPI 设备匹配机制是怎么回事儿?【最大特点是设备的自动发现和热插拔性能良好】
  • vue 组件开发
  • C++运动控制卡开发实践指南
  • 【pm2运行ts的终极解决方案】使用pm2+ tsx 运行 TypeScript 文件指南
  • 3.25-3 request断言
  • 代码随想录算法训练营第二十天 | 字符串 | 反转字符串、替换空格、翻转字符串里的单词(很多基础方法)和左旋转字符串
  • Windows下docker使用教程
  • 【C++特殊类的设计】
  • 和鲸科技执行总裁殷自强受邀主讲华中附属同济医院大模型应用通识首期课程
  • 美摄科技开启智能汽车车内互动及娱乐解决方案2.0
  • 音乐webpack(通杀webpack-1)
  • 解决在客户端本地无法访问服务器http方式访问麦克风与摄像头的问题
  • Linux如何判断磁盘是否已分区?
  • 基于yolov11的中空圆柱形缺陷检测系统python源码+pytorch模型+评估指标曲线+精美GUI界面
  • (C语言)静态通讯录(正式版)(C语言小项目)
  • HTML5 Geolocation(地理定位)学习笔记
  • 微网站建设公司哪家好/谷歌优化培训
  • 360免费wifi连不上/青岛网站建设方案优化
  • 自己做电商网站./国家职业技能培训学校
  • 云南住房和城乡建设厅网站/关键词排名批量查询软件
  • 网站负责人拍照/手机系统优化工具
  • 部门网站建设怎么做/怎么样在百度上推广自己的产品