更新 Paxos 内容

balance/global-load-balancer.md

@@ -1,9 +1,11 @@
 # 4.6 全局负载均衡设计
 
-未来的负载均衡系统将越来越将单个负载均衡器视为通用的标准化组件，统一由全局控制系统进行管理。图 4-14 展示了全局负载均衡系统的示例，包含以下内容：
+未来的负载均衡系统将越来越将单个负载均衡器视为通用的标准化组件，统一由全局控制系统进行管理。
+
+图 4-14 展示了全局负载均衡系统的示例，包含以下内容：
 - 每个边车代理（Sidecar Proxy）同时和位于三个 Zone 的后端通信；
-- 边车代理和后端定期向全局负载均衡器（Global Load Balancer）汇报状态。全局负载均衡器根据延迟、负载、请求失败率等参数做出最合适的配置；
-- 全局负载均衡器向边车代理下发配置。根据图 4-10，可以看到 90% 的流量到了 Zone C，Zone A 和 B 各只有 5%。
+- 边车代理、后端定期向全局负载均衡器（Global Load Balancer）汇报延迟、负载、请求失败率等运行状态，全局负载均衡器综合全局状态信息做出最合适的配置策略；
+- 全局负载均衡器向边车代理下发配置策略，可以看到 90% 的流量到了 Zone C，Zone A 和 B 各只有 5%。
 
 :::center
   ![](../assets/global-load-balancer.svg)<br/>
@@ -12,9 +14,8 @@
 
 在分布式负载均衡场景中，全局负载均衡器能够实现太多单一负载均衡器无法完成的功能。例如：
 
-- 在多个区域间实现自动故障转移：当某个区域出现故障或负载过高时，自动将流量切换到其他可用区域；
-- 利用机器学习和神经网络技术检测并缓解流量异常，如识别并治理 DDoS 攻击；
-- 应用全局安全和路由策略，确保配置的一致性；
-- 提供可视化运维平台，帮助工程师直观理解并维护整个分布式系统。
+- 当某个区域故障或负载过高时，全局负载均衡器自动将流量切换到其他可用区；
+- 利用机器学习、神经网络技术检测并缓解流量异常问题。例如，识别治理 DDoS 攻击；
+- 收拢各个边车代理配置，提供可视化的全局运维平台，帮助工程师直观理解、维护整个分布式系统。
 
-全局负载均衡器在服务网格中被称为“控制平面”（Control Plane）。控制平面与边车代理协作的关键在于动态配置的实现。笔者将在 8.7 节介绍 xDS 协议时，阐述这一部分内容。
+全局负载均衡器的设计在服务网格领域被称为“控制平面”（Control Plane）。控制平面与边车代理协作的关键在于如何实现配置的动态化。笔者将在 8.7 节介绍 xDS 协议时，阐述这一部分内容。

consensus/Basic-Paxos.md

@@ -7,7 +7,7 @@
 
 在 Paxos 算法中，节点分为三种角色。
 
-- **提议者（Proposer）**：提议者是启动共识过程的节点，它提出一个值，并请求其他节点对这个值进行投票，提出值的行为被称为“提案"（Proposal）。注意的是，Paxos 算法是一个典型的为“操作转移”模型设计的算法，为简化表述，本文把提案类比成“变量赋值”操作，但你应该理解它是“操作日志”相似的概念，后面介绍的 Raft 算法中，直接就把“提案”称做“日志”了。
+- **提议者（Proposer）**：提议者是启动共识过程的节点，它提出一个值，并请求其他节点对这个值进行投票，提出值的行为被称为“提案"（Proposal），提案包含提案编号 (Proposal ID) 和提议的值 (Value)。注意的是，Paxos 算法是一个典型的为“操作转移”模型设计的算法，为简化表述，本文把提案类比成“变量赋值”操作，但你应该理解它是“操作日志”相似的概念，后面介绍的 Raft 算法中，直接就把“提案”称做“日志”了。
 - **决策者（Acceptor）**：接受或拒绝 Proposer 的提案，如果一个提案被超过半数的 Acceptor 接受，那提案意味着被“批准”（accepted）。提案一旦被批准，意味着在所有节点中达到共识，便不可改变、永久生效。
 - **记录者（Learner）**：记录者发不起提案，也不参与决策提案，但它们需要学习并知道哪些提案被接受作为最终决策。
 

consensus/Multi-Paxos.md

@@ -13,7 +13,7 @@
   图 6-14 当节点收到客户端的请求命令 jmp（提案）时情况
 :::
 
-决议jump 提案时经历了 3 轮 Basic Paxos，花费 6 个 RTT（日志不顺序，以及 Basic Paxos 本身就需要 2 个 RTT）。此外，当多个节点同时发起提案时，还导致频繁出现活锁。
+决议jump 提案时经历了 3 轮 Basic Paxos，花费 6 个 RTT（日志顺序不一致，以及 Basic Paxos 本身就需要 2 个 RTT）。此外，当多个节点同时发起提案时，还导致频繁出现活锁。
 
 形成活锁的原因是 Paxos 算法中“节点众生平等”，每个节点都可以并行的发起提案。如何不破坏 Paxos 的“节点众生平等”基本原则，又能在提案节点中实现主次之分，限制每个节点都有不受控的提案权利？这是共识算法从理论研究走向实际工程的第一步；
 如何就多个值形成决议，并在过程成解决网络通信效率问题?，这是共识算法走向实际工程的第二步；解决了上述两个问题，并在过程中保证安全性。就认为是一个可“落地”的共识系统。
@@ -22,6 +22,6 @@ Multi Paxos 算法对此的改进是增加“选主”机制。节点之间就
 
 一旦选举出多数节点接受的领导者。那领导者就可以跳过 Basix Paxos 中 Prepare 多数派承诺阶段，直接向其他节点广播 Accept 消息即可。这样一个提案达成共识，只需要一轮 RPC。
 
-不过呢，Lamport 的论文主要关注的是 Basic Paxos 的算法基础和正确性证明，虽然在理论上做了 Multi Paxos 扩展，但没有深入描述如何通过领导者角色解决多轮提案的效率问题，且没有给出充分的优化细节。2014 年，斯坦福的学者 Diego Ongaro 和 John Ousterhout 发表了论文《In Search of an Understandable Consensus Algorithm》，提出了 Multi-Paxos 思想上简化和改进的 Raft 算法，明确提出了“选主”、“日志复制”等概念以及实现细节的描述。该论文斩获 USENIX ATC 2014 大会 Best Paper 荣誉，Raft 算法更是成为 etcd、Consul 等分布式系统的实现基础。
+不过呢，Lamport 的论文主要关注的是 Basic Paxos 的算法基础和正确性证明，虽然在 Basic Paxos 之上做了 Multi Paxos 扩展，但没有深入描述如何通过领导者角色解决多轮提案的效率问题，且没有给出充分的优化细节。2014 年，斯坦福的学者 Diego Ongaro 和 John Ousterhout 发表了论文《In Search of an Understandable Consensus Algorithm》，提出了 Multi-Paxos 思想上简化和改进的 Raft 算法，明确提出了“选主”、“日志复制”等概念以及实现细节的描述。该论文斩获 USENIX ATC 2014 大会 Best Paper 荣誉，Raft 算法更是成为 etcd、Consul 等分布式系统的实现基础。
 
 

consensus/conclusion.md

@@ -1,10 +1,9 @@
 # 6.5 小结
 
-Paxos 以及 Raft 算法属于故障容错（Crash Fault Tolerance，CFT）算法的范畴，解决的是分布式系统中存在故障，但不存在恶意节点下的分布式共识问题。
+Paxos 论文的意义在于它首次定义了分布式系统中的一致性问题，并提供了一种可验证的数学模型。
 
-如果把共识问题扩展到包含恶意节点的情况时，那便进入了最困难、最复杂的分布式故障场景 —— 拜占庭容错（Byzantine Fault Tolerance）领域。谈及此处，你大概率会联想到数字货币和 Web3 等区块链技术。没错，这些技术正是基于拜占庭容错算法（譬如 PBFT、PoW）达成共识，从而实现了去中心化网络中的安全性和一致性。
+Paxos 开创了分布式共识研究的先河，不仅成为许多分布式系统课程和教材中的经典内容，而且它的思想和技术也广泛应用于许多工业系统中。例如，Google 的 Chubby 锁服务、Amazon 的 Dynamo 系统、Apache Kafka 和 Zookeeper 等，都采纳了 Paxos 或其衍生算法来实现分布式一致性和容错机制。毫无疑问，Paxos 算法是分布式系统领域最具影响力的算法之一。不夸张地说，如果没有 Paxos 算法的先驱性工作，区块链、分布式系统、云计算等领域的发展可能会推迟数年甚至十几年。
 
-限于篇幅以及笔者的精力，这部分内容就不再展开讨论，有兴趣的读者就自行探索吧。
 
 参考文档：
 - https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying

consensus/summary.md

@@ -10,11 +10,7 @@
 
 分布式系统存在太多可能出错的场景了，网络数据包可能会丢失、顺序紊乱，重复发送或者延迟，节点还可能宕机。
 
-分布式系统中最重要的抽象之一就是共识。共识是所有的节点就某一项提议达成一致。
-
-本章我们讨论如何在无序、冲突和不可靠的网络环境下实现分布式共识，共识是确保所有节点对某个决策达成一致的关键，如何实现共识是软件工程领域中最具挑战的难题之一。
-
-这一章，我们知难而上，从解决问题的角度理解什么是共识，沿着 Paxos 论文讨论如何建立共识，再以工程实践为目的学习 Raft 的设计思路。最后，理解了这些问题以及共识算法的解题思路，自然能体会到 etcd、consul 以及各类分布式容错系统的设计原理，以及领悟到构建大规模分布式系统的要素。
+在充满不确定的环境下就某个决策达成一致，是软件工程领域中最具挑战的难题之一。这一章，我们知难而上，从解决问题的角度理解什么是共识，沿着 Paxos 论文讨论如何建立共识，以工程实践为目的学习 Raft 的设计思路。最后，理解了这些问题以及共识算法的解题思路，自然能体会到 Apache Kafka、 Zookeeper、etcd、consul 以及各类分布式容错系统的设计原理、领悟到构建大规模分布式系统的要素。
 
 :::center
   ![](../assets/consensus-summary.png) <br/>