分布式一致性算法-Paxos、Raft、ZAB、Gossip

本文链接：https://blog.youkuaiyun.com/qq_30472581/article/details/105512295

本文介绍了分布式一致性的重要性，详细讲解了Paxos、Raft、ZAB（ZooKeeper原子广播协议）和Gossip四种算法的工作原理，包括它们的一致性分类和实现案例。Paxos与Raft是强一致性算法，常用于分布式系统中的数据同步，而Gossip则是弱一致性算法，适用于最终一致性场景。文中还分析了各种算法的特点和适用场景。

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

分布式一致性算法

参考文献

注：全文共2206字，配图较多，建议收藏后食用

一致性算法简介

为什么需要一致性

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

一致性算法的定义

一致性就是数据保持一致，在分布式系统中，可以理解为多个节点中数据的值是一致的。

一致性的分类

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

一致性算法实现举例

Google的Chubby分布式锁服务，采用了Paxos算法
etcd分布式键值数据库，采用了Raft算法
ZooKeeper分布式应用协调服务，Chubby的开源实现，采用ZAB算法

强一致性算法

Paxos算法

概念介绍
1. Proposal提案，即分布式系统的修改请求，可以表示为**[提案编号N，提案内容value]**
2. Client用户，类似社会民众，负责提出建议
3. Propser议员，类似基层人大代表，负责帮Client上交提案
4. Acceptor投票者，类似全国人大代表，负责为提案投票，不同意比自己以前接收过的提案编号要小的提案，其他提案都同意，例如A以前给N号提案表决过，那么再收到小于等于N号的提案时就直接拒绝了
5. Learner提案接受者，类似记录被通过提案的记录员，负责记录提案
Basic Paxos算法
- 步骤
1. Propser准备一个N号提案
2. Propser询问Acceptor中的多数派是否接收过N号的提案，如果都没有进入下一步，否则本提案不被考虑
3. Acceptor开始表决，Acceptor无条件同意从未接收过的N号提案，达到多数派同意后，进入下一步
4. Learner记录提案