Paxos

最新推荐文章于 2024-07-27 22:14:50 发布

Deapou

最新推荐文章于 2024-07-27 22:14:50 发布

阅读量432

点赞数

分类专栏：区块链文章标签：分布式 paxos 共识算法

本文链接：https://blog.csdn.net/qq_42224330/article/details/113790582

版权

区块链专栏收录该内容

8 篇文章 4 订阅

订阅专栏

简介

Paxos 其实是一类能够解决分布式一致性问题的协议，它能够让分布式网络中的节点在出现错误时仍然保持一致；Leslie Lamport 提出的 Paxos 可以在没有恶意节点的前提下保证系统中节点的一致性，也是第一个被证明完备的共识算法，目前的完备的共识算法包括 Raft 本质上都是 Paxos 的变种。

作为一类协议，Paxos 中包含 Basic Paxos、Multi-Paxos、Cheap Paxos 和其他的变种

Basic Paxos

Basic Paxos 是 Paxos 中最为基础的协议，每一个 Basic Paxos 的协议实例最终都会选择唯一一个结果；使用 Paxos 作为共识算法的分布式系统中，节点都会有三种身份，分别是 Proposer、Acceptor 和 Learner：
在这里插入图片描述

我们在这里会忽略最后一种身份 Learner 简化协议的运行过程，便于读者理解；Paxos 的运行过程分为两个阶段，分别是准备阶段（Prepare）和接受阶段（Accept），当 Proposer 接收到来自客户端的请求时，就会进入如下流程：
在这里插入图片描述

在整个共识算法运行的过程中，Proposer 负责提出提案并向 Acceptor 分别发出两次 RPC 请求，Prepare 和 Accept；Acceptor 会根据其持有的信息 minProposal、acceptedProposal 和 acceptedValue 选择接受或者拒绝当前的提案，当某一个提案被过半数的 Acceptor 接受之后，我们就认为当前提案被整个集群接受了。
在这里插入图片描述

我们简单举一个例子介绍 Paxos 是如何在多个提案下保证最终能够达到一致性的，上述图片中 S1 和 S5 分别收到了来自客户端的请求 X 和 Y，S1 首先向 S2 和 S3 发出 Prepare RPC 和 Accept RPC，三个服务器都接受了 S1 的提案 X；在这之后，S5 向 S3 和 S4 服务器发出 Prepare(2.5) 的请求，S3 由于已经接受了 X，所以它会返回接受的提案和值 (1.1, X)，这时服务器使用接收到的提案代替自己的提案 Y，重新向其他服务器发送 Accept(2.5, X) 的 RPC，最终所有的服务器会达成一致并选择相同的值。

Multi-Paxos

由于大多数的分布式集群都需要接受一系列的值，如果使用 Basic Paxos 来处理数据流，那么就会导致非常明显的性能损失（所有的用户要两两交互），而 Multi-Paxos 是前者的加强版，如果集群中的 Leader 是非常稳定的，那么我们往往不需要准备阶段的工作，这样就能够将 RPC 的数量减少一半。
在这里插入图片描述

上述图片中描述的就是稳定阶段 Multi-Paxos 的处理过程，S1 是整个集群的 Leader，当其他的服务器接收到来自客户端的请求时，都会将请求转发给 Leader 进行处理。
当然，Leader 角色的出现自然会带来另一个问题，也就是 Leader 究竟应该如何选举，在 Paxos Made Simple 一文中并没有给出 Multi-Paxos 的具体实现方法和细节，所以不同 Multi-Paxos 的实现上总有各种各样细微的差别。
在这里插入图片描述

Paxos算法的解决的问题描述

假设有一组可以提出（propose）value（value在提案Proposal里）的进程集合。一个一致性算法需要保证提出的这么多value中，只有一个value被选定（chosen）。如果没有value被提出，就不应该有value被选定。如果一个value被选定，那么所有进程都应该能学习（learn）到这个被选定的value。对于一致性算法，安全性（safaty）要求如下：
• 只有被提出的value才能被选定。

• 只有一个value被选定，并且如果某个进程认为某个value被选定了，那么这个value必须是真的被选定的那个。

• Paxos的目标：保证最终有一个value会被选定，当value被选定后，进程最终也能获取到被选定的value

Paxos算法的过程

第一阶段-prepare阶段

• proposer选择一个提案编号（N），然后想半数以上的acceptor发送编号为N的提案。prepare（N）。这里的编号N只是一个数字，用于标记作用。真正的内容是里面的value。

• 如果一个Acceptor收到一个编号为N的Prepare请求，如果小于它已经响应过的请求，则拒绝，不回应或回复error。若N大于该Acceptor已经响应过的所有Prepare请求的编号（maxN），那么它就会将它已经接受过（已经经过第二阶段accept的提案）的编号最大的提案（如果有的话，如果还没有的accept提案的话返回{pok，null，null}）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。

第二阶段-accept阶段

• 如果一个Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。
注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案（就是propose人接收到的都是{pok，null，null}），那么V就由Proposer自己决定。

• 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。如果N小于Acceptor以及响应的prepare请求，则拒绝，不回应或回复error（当proposer没有收到过半的回应，那么他会重新进入第一阶段，递增提案号，重新提出prepare请求）。

• 在上面的运行过程中，每一个Proposer都有可能会产生多个提案。但只要每个Proposer都遵循如上述算法运行，就一定能保证算法执行的正确性。
在这里插入图片描述