From 4b2016dc59b6db6b4d1320e9f1a3bd9b01490fb0 Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 6 Dec 2024 15:39:45 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=94=99=E8=AF=AF?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- consensus/Basic-Paxos.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/consensus/Basic-Paxos.md b/consensus/Basic-Paxos.md index 2081004b..369d5a0b 100644 --- a/consensus/Basic-Paxos.md +++ b/consensus/Basic-Paxos.md @@ -22,9 +22,9 @@ Paxos 是基于 Quorum 的算法，但“少数服从多数”并不能解决所 图 6-5 网络延迟导致冲突 ::: -根据图 6-5，你会发现提案冲突的矛盾在于 S~3~，S~3~ 是两个 Quorum 的交集点，它的时间线上有两个不同的值被批准。 +根据图 6-5，你会发现提案冲突发生在 S~3~，S~3~ 是两个 Quorum 的交集点，它的时间线上有两个不同的值被批准。 -我们知道，程序设计中的一个基本常识是：如果多个线程同时操作某个共享变量，一定要加上互斥锁，不然会出现各种意外情况。所以，S~3~ 问题的本质是：“在分布式环境下并发操作共享变量的问题”。 +我们知道，程序设计中的一个基本常识是，如果多个线程同时操作某个共享变量，一定要加上互斥锁，不然会出现各种意外情况。所以，S~3~ 问题的本质是：“在分布式环境下并发操作共享变量的问题”。 我们不能简单“套用”进程加锁的机制解决 S~3~ 的问题，因为分布式环境下可能随时会出现通信故障，如果一个节点获得锁之后，释放锁之前故障了，整个系统就会被无限期等待阻塞。因此，必须提供一种可供其他节点抢占锁的机制，避免因通信故障出现的死锁问题。 @@ -49,7 +49,7 @@ Paxos 算法的第一个阶段称“准备阶段”（Prepare）。提议者选 - 尚未承诺 $\mathit{≥N}$ 编号的提案：则“承诺”（promise）不再接受任何编号小于 $\mathit{N}$ 的提案，返回一个响应，其中包含承诺的提案编号以及对应的提案值（如果有）； - 已承诺 $\mathit{≥N}$ 编号的提案：拒绝当前的 Prepare 请求，不返回任何响应。 -提议者从多数决策者获得了“承诺”（Promise），则“准备阶段”达成。接着，决策者选择提案值：如果决策者的响应中返回了提案值，从中选择编号最高的提案值；如果没有返回的提案值，则使用决策者初始提案值。 +提议者从多数决策者获得了“承诺”（Promise），则“准备阶段”达成。接着，决策者选择提案值：如果决策者的响应中返回了提案值，从中选择编号最高的提案值；如果没有提案值返回，则使用决策者初始提案值。 完成以上操作后，进入下一个阶段。 @@ -64,7 +64,7 @@ Paxos 算法的第二个阶段称“批准阶段”（Accept）。提议者向 证明 Paxos 算法的正确性比重新实现 Paxos 算法还难。我们没必须推导 Paxos 的正确性，通过以下几个例子来验证 Paxos 算法的运行机制。 -下面的示例中，X、Y 代表客户端，S~1~ ~ S~5~ 是服务端，它们既是提议者又是决策者，图中的 P 代表 “准备阶段”，A 代表“批准阶段”。为了便于理解，提案编号$\mathit{N}$ 由自增序号.Server ID 组成。例如，S~1~ 的提案编号，就是 1.1、2.1、3.1...。 +下面的示例中，X、Y 代表客户端，S~1~ ~ S~5~ 是服务端，它们既是提议者又是决策者，图中的 P 代表 “准备阶段”，A 代表“批准阶段”。为了便于理解，提案编号$\mathit{N}$ 由自增序号和 Server ID 组成。例如，S~1~ 的提案编号为 1.1、2.1、3.1...。 下面我们分析该集群就一个“提案选取值 X 还是 Y ”进行决议，会出现什么情况。