修改错误

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 ”进行决议，会出现什么情况。