Zookeeper核心知识及分布式一致性算法

置顶

aotulive

已于 2023-08-26 10:42:53 修改

阅读量1.7k

点赞数 2

分类专栏： java学习之路随笔 Zookeeper 文章标签：分布式 zookeeper 一致性算法 ZAB Paxos

于 2020-09-24 09:52:44 首次发布

本文链接：https://blog.csdn.net/aotumemedazhao1996/article/details/108755565

版权

Zookeeper是一个提供分布式协调服务的开源项目，其核心能力在于数据一致性。Zookeeper基于ZAB协议保证集群一致性，该协议是Paxos算法的优化版。文章详细介绍了Paxos算法的流程、角色和缺陷，接着讲解了Raft算法的角色、选举机制和安全性。ZAB协议与Paxos和Raft类似，但更注重快速恢复，包括选举、发现、同步和广播四个阶段。通过对这些一致性算法的理解，有助于深入认识Zookeeper如何在分布式环境中确保数据的一致性。

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

Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。而这些功能都是基于Zookeeper能在分布式的集群中保证数据一致性的，这也是Zookeeper最核心的能力。
Zookeeper集群对数据的一致性的保证和Zookeeper集群高可用这两个核心功能归纳为两个知识点：
1.ZAB（ ZooKeeper Atomic Broadcast , ZooKeeper 原子消息广播协议）
2.Zookeeper选举机制

本篇主要说分布式一致性算法。如果只关注ZAB，可以跳过 Paxos、Raft 章节，直接从ZAB开始阅读，强烈建议从头到尾阅读，这样对ZAB协议理解会更深入。

一致性算法
由来

数据不能存在单个节点（主机）上，否则可能出现单点故障。
多个节点（主机）需要保证具有相同的数据。
一致性算法就是为了解决上面两个问题。

分类

强一致性：保证系统改变提交以后立即改变集群的状态。
- Paxos
- Raft（muti-paxos 对Paxos改进）
- ZAB（muti-paxos 对Paxos改进）
弱一致性：也叫最终一致性，系统不保证改变提交以后立即改变集群的状态，但是随着时间的推移最终状态是一致的。
- DNS系统
- Gossip协议

弱一致性算法这里不讲，感兴趣可以自行百度了解。

Zookeeper的ZAB协议以及Raft都是基于Paxos改进和优化而来的，Paxos有多重要吶？
在这里插入图片描述

Paxos

Paxos 算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。zookeeper 使用的 zab 算法是该算法的一个实现。
在 Paxos 算法中，把数据修改用提案标识：Proposal:提案，即分布式系统的修改请求，可以表示为[提案编号N，提案内容value]
在 Paxos 算法中有三种角色：Proposer，Acceptor，Learners

Proposer：发起提案，只要 Proposer 发的提案被半数以上 Acceptor 接受，Proposer 就认为该提案里的 value 被选定了。
Acceptor:只要 Acceptor 接受了某个提案，Acceptor 就认为该提案里的 value 被选定了。不同意比自己以前接收过的提案编号要小的提案，其他提案都同意，例如A以前给N号提案表决过，那么再收到小于等于N号的提案时就直接拒绝了
Learners:Acceptor 告诉 Learner 哪个 value 被选定，Learner 就认为那个 value 被选定。类似记录被通过提案的记录员，负责记录提案

流程

Paxos 算法分为两个阶段。具体如下：

阶段一（准 leader 确定）：

Proposer 选择一个提案编号 N，然后向半数以上的 Acceptor 发送编号为 N 的 Prepare 请求。
如果一个 Acceptor 收到一个编号为 N 的 Prepare 请求，且 N 大于该 Acceptor 已经响应过的所有 Prepare 请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应Propose反馈给 Proposer，同时该 Acceptor 承诺不再