分布式系统

Observability/dumps.md

@@ -22,4 +22,4 @@ A small number of signals which cause abnormal termination of a process
 
 此外，CNCF 发布的可观测性白皮书中仅提及了 core dump。实际上，dumps 范围应该扩展到 Heap dump（Java 堆栈在特定时刻的快照）、Thread dump（特定时刻的 Java 线程快照）和 Memory dump（内存快照）等等。
 
-虽然 CNCF 将 dumps 纳入可观测性体系，但面临业务容器与操作系统全局配置的冲突、数据持久化的挑战（在 Pod 重启前需要将数 Gb 的 core dump 文件写入持久卷）等众多技术难题，导致处理和分析 dumps 数据仍然得用传统的手段。
+虽然 CNCF 将 dumps 纳入可观测性体系，但仍有许多技术难题，如业务容器与操作系统全局配置的冲突、数据持久化的挑战（在 Pod 重启前需要将数 Gb 的 core dump 文件写入持久卷）等，导致处理 dumps 数据还得依靠传统手段。

consensus/conclusion.md

@@ -1,8 +1,12 @@
 # 6.5 小结
 
-Paxos 论文的意义在于它首次定义了分布式系统中的一致性问题，并提供了一种可验证的数学模型。
+做架构设计最难的是“如何支撑海量请求”，解决这一挑战的核心在于分布式系统。分布式系统的关键问题是：如何在节点可能故障的情况下，确保对某个操作达成一致。
+
+尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识的研究。Paxos 通过多数派投票机制和两阶段协议（Prepare 和 Accept）明确了对单个值达成共识。解决了单值一致性问题后，执行多次 Paxos 算法即可实现一系列值的共识，这便是 Multi-Paxos 的核心思想。基于 Multi-Paxos 思想，将整个共识过程分解为几个子问题：领导者选举、日志复制和安全性，这就是易理解、易论证、易实现的 Raft 算法。
+
+
+在充满不确定性的世界中建立秩序，保证了系统的可靠性和一致性，这才有了区块链（以太坊、比特币）、分布式系统、云计算等大放异彩的故事。
 
-Paxos 开创了分布式共识研究的先河，不仅成为许多分布式系统课程和教材中的经典内容，而且它的思想和技术也广泛应用于许多工业系统中。例如，Google 的 Chubby 锁服务、Amazon 的 Dynamo 系统、Apache Kafka 和 Zookeeper 等，都采纳了 Paxos 或其衍生算法来实现分布式一致性和容错机制。毫无疑问，Paxos 算法是分布式系统领域最具影响力的算法之一。不夸张地说，如果没有 Paxos 算法的先驱性工作，区块链、分布式系统、云计算等领域的发展可能会推迟数年甚至十几年。
 
 
 参考文档：

consensus/raft-ConfChange.md

@@ -26,8 +26,7 @@
 
 最初，Diego Ongaro 在论文中提出了一种基于两阶段的“联合共识”（Joint Consensus）成员变更方案，但这种方案实现起来很复杂。后来，Diego Ongaro 又提出的一种更简单的方案 —— “单成员变更”（Single Server Changes）。单成员变更的思路是，既然同时提交多个成员变更会存在问题，那每次就提交一个成员变更，如果要添加多个成员，那就执行多次单成员变更方案。
 
-单成员变更方案很容易穷举出所有情况，如图 6-22 所示，穷举集群奇/偶数节点下添加/删除情况。如果每次只操作一个节点，那么 **C~old~ 的 Quorum 和 C~new~ 的 Quorum 之间一定存在交集**。同一个 term 中，C~old~ 和 C~new~ 中交集的那个节点只会进行一次投票，要么投票给 C~old~，要么投票给 C~new~，不可能出现两个符合条件的 Quorum，也就不会出现两个 Leader。
-
+单成员变更方案很容易穷举出所有情况，如图 6-22 所示，穷举集群奇/偶数节点下添加/删除情况：如果每次只操作一个节点，那么 **C~old~ 的 Quorum 和 C~new~ 的 Quorum 之间一定存在交集**，交集的那个节点只会进行一次投票，要么投票给 C~old~，要么投票给 C~new~。因此，不可能出现两个符合条件的 Quorum，也就不会出现两个 Leader。
 
 以图 6-16 第二种情况为例，C~old~ 为 [Server1、Server2、Server3]，该集群的 Quorum 为（N/2）+1 = 2，C~new~ 为 [Server1、Server2、Server3、Server4]，该集群的 Quorum 为（N/2）+1 = 3。假设 Server1、Server2 比较迟钝，还在用 C~old~ ，其他节点的状态机已经“apply” C~new~：
 - 假设 Server1 触发选举，赢得 Server1，Server2 的投票，满足  C~old~ Quorum 要求，当选 Leader；

consensus/raft.md

@@ -25,6 +25,6 @@ Raft is a consensus algorithm for managing a replicated log. It produces a resul
 
 此后，Raft 算法成为分布式系统领域的首选共识算法。
 
-接下来，笔者将以领导者角色、选举、日志提交等设计机制，讲解 Raft 算法是如何妥善解决分布式系统一致性需求的。
+接下来，笔者将以领导选举、日志复制为主题，讲解 Raft 算法是如何妥善解决分布式系统一致性需求的。
 
 [^1]: 论文参见 https://raft.github.io/raft.pdf

container/kube-scheduler.md

@@ -1,8 +1,8 @@
 # 7.7.3 调度器与扩展设计
 
-如果集群只有几十个节点，为新创建的 Pod 找到最合适的节点并不困难，但当节点规模达到几千台甚至更多时，问题就变得复杂了：
-- 首先，Pod 的创建/更新和节点资源无时无刻不在发生变化，如果每次调度都需要数千次远程请求获取相关信息，势必因耗时过长，导致调度失败率过高。
-- 另一方面，调度器频繁的网络请求极容易使其成为集群的性能瓶颈。
+如果集群中节点的数量只有几十个，为新创建的 Pod 找到最合适的节点并不困难。但当节点的数量扩大到几千台甚至更多时，问题就变得复杂了：
+- 首先，Pod 的创建、更新还有节点资源无时无刻不在变化，如果每次调度都需要数千次远程请求获取信息，势必因耗时过长，增加调度失败的风险。
+- 其次，调度器频繁发起网络请求，极容易成为集群性能的关键瓶颈，影响整个集群的运行效率。
 
 :::tip <a/>
 为了充分利用硬件资源，通常会将各种类型(CPU 密集、IO 密集、批量处理、低延迟作业)的 workloads 运行在同一台机器上，这种方式减少了硬件上的投入，但也使调度问题更加复杂。

http/quic.md

@@ -4,7 +4,7 @@ QUIC（Quick UDP Internet Connection，快速 UDP 网络连接）是一种基于
 
 许多人可能认为是 IETF 在推动 QUIC 替代 TCP。实际上，QUIC 的开发始于 Google。
 
-早在 2013 年，Google 就在其后端服务（如 Google.com 和 YouTube.com）及 Chrome 浏览器中启用了名为“QUIC”（业内称为 gQUIC）的全新传输协议。2015 年，Google 将 gQUIC 提交给 IETF，经 IETF 规范化后的 QUIC 被称为“iQUIC”。早期的 iQUIC 有多个“草稿”版本，如 h3-27、h3-29 和 h3 v1 等。2018 年末，IETF 发布了基于 QUIC 协议的新一代互联网标准 HTTP/3。
+早在 2013 年，Google 就在自家服务（如 google.com、youtube.com）及 Chrome 浏览器中启用了名为“QUIC”（业内称为 gQUIC）的全新传输协议。2015 年，Google 将 gQUIC 提交给 IETF，经 IETF 规范化后的 QUIC 被称为“iQUIC”。早期的 iQUIC 有多个“草稿”版本，如 h3-27、h3-29 和 h3 v1 等。2018 年末，IETF 发布了基于 QUIC 协议的新一代互联网标准 HTTP/3。
 
 图 2-26 展示了各个 HTTP 协议的区别。可以看出，HTTP/3 最大的特点是：底层基于 QUIC 协议，默认集成了 TLS 安全协议。
 
@@ -62,7 +62,7 @@ QUIC 内部集成了 TLS 安全协议，无需像 TCP 先经过三次握手，
 
 如图 2-29 所示，若一个属于 Stream2 的 TCP 数据包丢失（如图中标记为 5 的圆圈），将导致后续数据包的传输阻塞。该问题就是业界常常提到的“队头阻塞”（head-of-line blocking）。
 
-相比之下，**QUIC 为每个 Stream 设计了独立的控制机制，Stream 之间没有顺序依赖**。这意味着，如果一个属于 Stream2 的 UDP 数据包丢失，它只会影响 Stream2 的处理，不会阻塞 Stream1 和 Stream3 的传输。
+相比之下，**QUIC 为每个 Stream 设计了独立的控制机制，Stream 之间没有先后依赖**。这意味着，如果一个属于 Stream2 的 UDP 数据包丢失，它只会影响 Stream2 的处理，不会阻塞 Stream1 和 Stream3 的传输。
 
 这样的设计有效避免了 TCP 协议中的队头阻塞问题。