1. 概念
分布式共识算法是一类算法,用于在分布式系统中达成多个节点之间的一致性决策。由于分布式系统中各个节点可能会遇到网络延迟、节点故障或信息丢失等问题,分布式共识算法的目标是确保即使在这些不可靠的条件下,系统中的所有节点仍能就某个值或状态达成一致。
主要目标:
- 一致性:确保所有节点对某个值或状态达成一致。
- 容错性:即使部分节点发生故障,系统仍然能够继续运行并达成一致。
- 可用性:尽可能保证系统在大多数时间内可用,即使在发生故障的情况下。
2.常见算法
常见的我们了解下paxos以及raft即可。
2.1 paxos算法
Paxos 是一种经典的分布式共识算法,提供了一种在不可靠网络中达成一致的方法。尽管理论上非常强大,但由于其复杂性,在实际应用中实现和理解起来比较困难。
2.1.1角色与职责
-
提议者(Proposer) :
- 提议者负责提出提案(Proposal),希望其他节点接受该提案。
- 提议者可以是多个,彼此独立工作,通常由客户端请求触发。
-
接受者(Acceptor) :
- 接受者负责对提议者提出的提案进行投票。
- 每个接受者可以独立地接受或拒绝提案。
- 一旦大多数接受者接受某个提案,该提案就被选定。
-
学习者(Learner) :
- 学习者负责了解并应用最终被选定的提案。
- 学习者通常不参与提案的投票过程,但需要知道最终的决策。
2.1.2算法阶段
Paxos 算法主要分为两个阶段:准备阶段(Prepare Phase)和提议阶段(Propose Phase)。
准备阶段(Prepare Phase)
-
提议者选择提案编号:
- 提议者选择一个唯一的提案编号(Proposal Number),并向所有接受者发送“准备请求”(Prepare Request)。
-
接受者处理准备请求:
- 接受者收到准备请求后,检查提案编号是否大于它们已经响应过的所有提案编号。
- 如果是,接受者承诺不再接受编号小于该提案的新提案,并回复提议者。
- 回复中包含接受者已经接受的提案中编号最高的提案(如果有)。
提议阶段(Propose Phase)
-
提议者发送提案:
- 如果提议者收到大多数接受者的承诺,它就发送一个“提议请求”(Propose Request),包含提案编号和提议的值。
- 如果在准备阶段接受者回复中有编号更高的提案,提议者必须使用该提案的值。
-
接受者处理提议请求:
- 接受者如果没有对更高编号的提案做出承诺,就接受该提议。
- 一旦大多数接受者接受某个提案,该提案就被选定。
2.1.3关键特性
-
唯一性:
- Paxos 保证在任意时刻,最多只有一个提议会被选定,这确保了系统的一致性。
-
容错性:
- Paxos 能够容忍少数节点的故障,只要大多数节点仍然可用。
-
活性:
- 在没有故障的情况下,Paxos 能够最终达成一致,但在某些情况下,可能会由于竞争导致活性问题。
2.2 Raft算法
Raft 的目标是在分布式系统中实现强一致性,确保多个节点就某个值或状态达成一致,即使在某些节点发生故障的情况下。Raft 通过领导者选举、日志复制和安全性保证机制来实现这一目标。
2.2.1角色与职责
-
领导者(Leader) :
- 领导者负责处理所有客户端请求并管理日志复制过程。
- 每个任期内只有一个领导者,领导者通过心跳信号维持其角色。
-
跟随者(Follower) :
- 跟随者被动地接收领导者的日志条目和心跳信息。
- 如果跟随者在一定时间内没有收到领导者的信号,它会发起选举。
-
候选者(Candidate) :
- 在选举过程中,一个跟随者可以成为候选者以竞选领导者。
- 候选者向其他节点请求投票,并根据投票结果决定是否成为新的领导者。
2.2.2算法阶段
-
领导者选举:
- 当一个跟随者在预定时间内没有收到领导者的心跳信息时,会发起选举。
- 跟随者转变为候选者,并向其他节点请求投票。
- 如果候选者获得大多数节点的投票,它就成为新的领导者。
-
日志复制:
- 领导者将客户端请求作为日志条目追加到其日志中,并将这些条目复制到所有跟随者。
- 当一个日志条目在大多数节点上被提交时,它被认为是已提交的,并可以应用到状态机中。
-
安全性保证:
- Raft 确保如果一个日志条目在某个任期内被提交,那么在更高的任期内不会被覆盖。
- 通过选举限制和日志匹配限制,Raft 确保一致性。
2.2.3关键特性
-
易于理解:
- Raft 的设计目标之一是易于理解和实现,使开发者更容易在分布式系统中应用。
-
清晰的角色和阶段:
- 通过明确的角色分配和阶段划分,Raft 提供了更结构化的方式来处理共识问题。
-
高效的故障恢复:
- Raft 能够快速检测和恢复节点故障,通过领导者选举机制实现高可用性。
2.3 对比
| 特性 | Raft | Paxos |
|---|---|---|
| 易于理解和实现 | 设计目标是易于理解和实现 | 理论复杂度高,难以实现和理解 |
| 角色划分 | 明确划分为领导者、跟随者、候选者 | 角色不够明确 |
| 领导者选举 | 使用领导者选举机制,集中管理日志复制 | 无明确领导者,多个提议者并行工作 |
| 故障恢复 | 高效的领导者选举和故障转移 | 依赖复杂的提案投票机制 |