【分布式协调服务】--zookeeper实现原理

本文介绍了Zookeeper作为分布式协调服务的原理,包括其设计目标、集群架构、ZAB协议以及Leader选举机制。ZAB协议确保了数据的一致性和崩溃恢复,而Leader选举则通过fastleader算法进行,依据zxid和myid进行节点优先级判断,以保证集群的高效稳定运行。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、分布式协调机制引用的场景

  1. 各个节点的数据一致性
  2. 保证任务只在一个节点上执行
    最小节点(最先注册的节点)拿到执行权了之后,其他节点便没有权利执行。
  3. 如果一个节点挂了,怎么保证其他节点立刻知晓,并接替任务。
  4. 存在共享资源,互斥性,安全性如何保证。

二、zookeeper的设计

  1. 防止单点故障
    集群方案(leader,follower).还能分担请求
  2. 每个节点的数据是一致的(必须要有leader)
    leader,master;
  3. leader选举机制,数据恢复
  4. 如何保证数据一致性?(分布式事务)

改进版本的2PC协议

结论:

  1. zab来实现选举:
    集群内选举leader来调度简化集群的复杂度,
  2. 为什么要做集群:
    保证zookeeper协调工具的高性能和高可用(热备,同步)
  3. 2pc做数据一致性:
    引入了协调者(leader)和参与者(follower)的概念,具体见下方。

三、zookeeper集群

改进版的2PC事务:

  1. follower:处理读请求,转发写请求给leader
  2. leader接收到事务请求后会转发提议给集群中的每一个节点(observer除外)
  3. follwer节点收到提议后响应,返回ack
  4. leader收到过半节点响应ack,便会提交事务(commit),给客户端一个response。反之会执行回滚。
  5. 事务提交后会同步给Observer

3种角色特性:

  • leader:集群的核心,起到了主导整个集群的作用,事务请求的调度和处理。
  • follower:处理客户端的非事务请求,转发事务请求,参与事务的投票过程,参与leader选举投票
  • observer:观察者角色&
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值