更新分布式系统应用

balance/conclusion.md

@@ -1,12 +1,12 @@
 # 4.7 小结
 
-作为分布式系统的入口，负载均衡器的市场竞争激烈，技术创新层出不穷。各类负载均衡器技术无法逐一解释，但从处理请求的网络层次划分，所有的负载均衡器可分为两类：四层负载均衡和七层负载均衡。
+作为分布式系统的入口，负载均衡领域竞争激烈，技术创新层出不穷。各类负载均衡器技术无法逐一解释，但从处理请求的网络层次划分，所有的负载均衡器可分为两类：四层负载均衡和七层负载均衡。
 
-四层负载均衡器处理传输层连接，功能相对简单，主要依赖 IP 地址和端口信息进行流量分发。随着技术的不断演进，传统负载均衡设备（如 F5）逐渐被通用服务器之上，基于 IPVS、DPDK、fd.io 等框架的专用软件方案取代。例如，一台普通物理主机，在基于 DPDK 开发的流量转发或数据包处理场景下，能轻松达突破百万到数千万的 PPS（Packets Per Second，每秒处理的数据包数量）指标。
+四层负载均衡器处理传输层连接，功能相对简单，主要依赖 IP 地址和端口信息进行流量分发。随着技术的不断演进，传统负载均衡设备（如 F5）逐渐被通用服务器加上专用软件（如 IPVS、DPDK、fd.io）的方案取代。例如，一台普通物理主机，基于 DPDK 开发的流量转发或数据包处理场景下，能轻松达突破百万到数千万的 PPS（Packets Per Second，每秒处理的数据包数量）指标。
 
-七层负载均衡器处理应用层流量，职责更广，功能更强。如处理 HTTP 请求、SSL 卸载、URL 路由、Cookie 路由等。这几年，源于微服务架构的快速发展，该领域十分活跃。像传统代理软件（NGINX、HAProxy），也逐渐被更适应动态微服务架构后来者（Envoy、Traefik...）替代。
+七层负载均衡器处理应用层流量，职责更广、功能丰富。如处理 HTTP 请求、SSL 卸载、URL 路由、Cookie 路由等。这几年，源于微服务架构的快速发展，七层负载均衡领域十分活跃，像传统代理软件（NGINX、HAProxy），逐渐被更适应动态微服务架构后来者（Envoy、Traefik...）替代。
 
-总体而言，随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进，未来工程师将很少需要关注物理网络的工作原理。隐藏在通用软件方案中的各类网络技术，将逐渐演变为“黑科技”。
+总体而言，随着技术架构逐步向云厂商主导的 IaaS、CaaS 和 FaaS 模式演进，未来工程师将很少需要关注物理网络的工作原理。隐藏在通用软件方案中的各类网络技术，正逐渐演变为“黑科技”。
 
 参考文档：
 - 《现代网络负载均衡与代理导论》，https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236

balance/summary.md

@@ -1,10 +1,11 @@
 # 第四章：负载均衡与代理技术
 
 :::tip <a/>
-当你试图解释一条命令、一个语言特性或是一种硬件的时候，请首先说明它要解决的问题。
 
-:::right 
-—— 摘自《编程珠玑》[^1]
+一个篮子装不下所有的鸡蛋，那么就多用几个篮子来装。
+
+:::right
+—— 分布式系统的基本思想。
 :::
 
 或者出于扩展服务能力的考虑，又或者出于提高容错性的考虑，大多数系统通常以集群形式对外提供服务。
@@ -16,5 +17,3 @@
   ![](../assets/balance-summary.png)<br/>
   图 4-0 本章内容导读
 :::
-
-[^1]:《编程珠玑》作者是 Jon Bentley，被誉为影响算法发展的十位大师之一。在卡内基-梅隆大学担任教授期间，他培养了包括 Tcl 语言设计者 John Ousterhout、Java 语言设计者 James Gosling、《算法导论》作者之一Charles Leiserson 在内的许多计算机科学大家。

consensus/Replicated-State-Machine.md

@@ -40,7 +40,7 @@
 { "index": 9, "command": "set x=3" },
 ```
 
-节点内的进程(图中的 State Machine）依次执行日志序列。那么，所有节点最终成一致的状态。多个这样的进程加上有序的日志，就组成了我们熟知的各种分布式系统。
+节点内的进程(图中的 State Machine）依次执行日志序列。那么，所有节点最终成一致的状态。多个这样的进程加上有序的日志，就组成了我们所熟知的分布式存储、分布式消息队列、分布式锁等等各类分布式系统。
 
 :::center
   ![](../assets/Replicated-state-machine.webp) <br/>

consensus/conclusion.md

@@ -1,18 +1,8 @@
 # 6.5 小结
 
-做架构设计最难的是“如何支撑海量请求”，解决这一挑战的核心在于分布式系统。分布式系统的关键问题是：如何在节点可能故障的情况下，确保对某个操作达成一致。
+做架构设计最难的是“如何支撑海量请求”，解决这一挑战的核心在于分布式系统。分布式系统的关键问题是：**在不确定的环境下，仍然能够协商出一致的决策，对外呈现出一致的运行结果**。
 
-尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识的研究。Paxos 通过多数派投票机制和两阶段协议（Prepare 和 Accept）明确了对单个值达成共识。解决了单值一致性问题后，执行多次 Paxos 算法即可实现一系列值的共识，这便是 Multi-Paxos 的核心思想。基于 Multi-Paxos 思想，将整个共识过程分解为几个子问题：领导者选举、日志复制和安全性，这就是易理解、易论证、易实现的 Raft 算法。
+尽管 Paxos 是几十年前提出的算法，但它开创了分布式共识的研究。Paxos 通过多数派投票机制和两阶段协议（Prepare 和 Accept）明确了对单个值达成共识。解决了单值一致性问题后，执行多次 Paxos 算法即可实现一系列值的共识，这便是 Multi-Paxos 的核心思想。基于 Multi-Paxos 思想，将系统共识分解为几个子问题：领导者选举、日志复制和安全性，这就是易理解、易论证、易实现的 Raft 算法。
 
 
-在充满不确定性的世界中建立秩序，保证了系统的可靠性和一致性，这才有了区块链（以太坊、比特币）、分布式系统、云计算等大放异彩的故事。
-
-
-
-参考文档：
-- https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying
-- raft 动画，https://raft.github.io/raftscope/index.html
-- 《In Search of an Understandable Consensus Algorithm》，https://raft.github.io/raft.pdf
-- 《Raft 分布式系统一致性协议探讨》，https://zhuanlan.zhihu.com/p/510220698
-- 《Implementing Replicated Logs
-with Paxos》，https://ongardie.net/static/raft/userstudy/paxos.pdf
+毫不夸张地说，正是 Lamport 等科学家们的开创性工作（在混沌中建立秩序），这才有了区块链（以太坊、比特币）、分布式系统、云计算等大放异彩的故事。

consensus/consensus.md

@@ -1,6 +1,6 @@
 # 6.1 什么是共识
 
-在讨论 Paxos 或 Raft 时，很多文献使用“分布式一致性协议”或“分布式一致性算法”来描述这些技术。例如，Google Chubby 系统的作者 Mike Burrows 曾评价 Paxos：“There is only one consensus protocol...”，这一句话常被翻译为“世界上只有一种一致性算法”。
+讨论 Paxos 或 Raft 时，很多文献使用“分布式一致性协议”或“分布式一致性算法”来描述这些技术。例如，Google Chubby 系统的作者 Mike Burrows 曾评价 Paxos：“There is only one consensus protocol...”，这一句话常被翻译为“世界上只有一种一致性算法”。
 
 尽管“共识”和“一致”在汉语中含义相近，但在计算机领域，这两个术语具有截然不同的含义：
 

consensus/raft-leader-election.md

@@ -6,23 +6,23 @@ Raft 对此的改进是明确领导者角色，增加选举机制分享提案权
 
 - **Leader（领导者）**：负责处理所有客户端请求，将请求转换为“日志”复制到其他节点，确保日志在多数节点（Quorum）上被提交并生效。其次，定期向所有节点发送心跳，维持自己的领导地位。
 - **Follower（跟随者）**：接收 Leader 发送的日志条目，确认日志条目的写入情况，并向 Leader 发送响应。
-- **Candidate（）**：过渡角色 Candidate，Leader 丧失时，Follower 会转为 Candidate 参与选举；
+- **Candidate（候选人）**：过渡角色 Candidate，Leader 丧失时，Follower 会转为 Candidate 参与选举；
 
 
-联想到现实世界中的领导人都有一段不等的任期。自然，Raft 中的 Leader 也对应的概念 —— term。
+联想到现实世界中的领导人都有一段不等的任期。自然，Raft 中的 Leader 也对应的概念 —— term。任期是一个递增的数字，每次选举都会增加。
 
 - 任期越大，话语权越大：本地任期较小的总是服从任期更高的消息来源。
 - 每次选举，任期都会 +1：确保不会在多个选举过程中计票混乱。
 - 高任期的节点收到低任期节点的任何请求时，会直接拒绝。
 
-也就是说，任期是第一优先级的，节点进行“交流”（RPC 通信）时，只有对齐了任期，才有谈其他的基础。
+也就是说，任期是第一优先级。任期最大的节点内数据一定是最新的、最全的，最有资格成为 Leader 代表集群状态。
 
 :::center
   ![](../assets/raft-term.svg)
-  图 6-11 Raft term 与成员状态变更
+  图 6-11 Raft 通过任期的概念来分隔时间，每个任期开始都会进行一次领导者选举
 :::
 
-图 6-12 概述了 Raft 集群 Leader 选举过程。每个 Follower 在本地维持一个选举时钟，选举时钟到期时，如果没有收到 Leader 的日志或者心跳，follower 增加自己的 term，将身份切换为 candidate。向集群其它节点发送“请给自己投票”的消息（RequestVote RPC）。会发生下面的情况：
+图 6-12 概述了 Raft 集群 Leader 选举过程。跟随者在“选举超时”之内没有收到领导者的心跳，它将自己的任期号加一转变为候选者状态，其他节点广播“请给自己投票”的消息（RequestVote RPC），发起新一轮的选举：
 
 - **选举超时**：在固定时间内未收到其他节点的响应，或者收到的响应（同意票）的节点数量未达到 Quorum N/2+1 的要求。此时，触发选举超时进入下一轮选举；
 - **选举失败**：选举过程中，收到 Leader 心跳，或者发现有更高的 term，说明有新任期的 Leader，结束结束当前的选举。
@@ -33,15 +33,11 @@ Raft 对此的改进是明确领导者角色，增加选举机制分享提案权
   图 6-12 Raft 选举过程
 :::
 
-使用 Quorum 机制选举出的 Leader 代表了整个集群的意志。现在，你思考：“代表集群意志的 Leader 发起提案，是否还需要 Paxos 第一轮中 “准备阶段” 呢？”。
+在 Paxos 的选举过程中，常常会出现未达到指定票数而需要重新选举的情况。Raft 算法也面临类似的问题，但 Raft 巧妙地引入随机选举超时时间，通过将超时时间分散开来，Raft 保证大多数情况下只有一个服务器节点会先发起选举，而不是多个节点同时发起选举，这样就能减少了因选票分散导致选举失败的概率：
+- 跟随者等待领导者心跳超时的时间间隔，是随机的；
+- 如果候选人在一个随机时间间隔内，没有赢得过半票数，那么选举无效了，然后候选人发起新一轮的选举，也就是说，等待选举超时的时间间隔，也是随机的。
 
-
-
-
-
-
-
-
+使用 Quorum 机制选举出的 Leader 便代表了整个集群的意志。现在，你思考：“代表集群意志的 Leader 发起提案，是否还需要 Paxos 第一轮中 “准备阶段” 呢？”。
 
 
 

consensus/summary.md

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

distributed-transaction/CAP.md

@@ -2,7 +2,7 @@
 
 CAP 是分布式系统中关于一致性与可用性权衡的理论，是理解分布式系统的起点。
 
-1999 年，美国工程院院士 Eric A.Brewer 发表的论文《Harvest, Yield, and Scalable Tolerant Systems》[^1] 中，首次提出了 CAP 原理（CAP Principle）。不过彼时的 CAP 仅是一种猜想，尚未得到理论上的证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 用严谨的数学推理证明了 CAP 的正确性。此后，CAP 从原理转变成定理，在分布式系统领域产生了深远的影响。
+1999 年，美国工程院院士 Eric A.Brewer 发表了论文《Harvest, Yield, and Scalable Tolerant Systems》[^1] ，首次提出了 CAP 原理（CAP Principle）。不过，彼时的 CAP 仅是一种猜想，尚未得到理论上的证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 用严谨的数学推理证明了 CAP 的正确性。此后，CAP 从原理转变成定理，在分布式系统领域产生了深远的影响。
 
 :::center
   ![](../assets/cap-theorem.png) <br/>
@@ -15,17 +15,17 @@ CAP 定理描述的是**一个分布式系统中，涉及共享数据问题时
 - **可用性**（**A**vailability）：可用性代表系统持续提供服务的能力。要理解可用性，首先需要了解两个密切相关的指标：可靠性（Reliability）和可维护性（Serviceability）。可靠性通过平均无故障时间（MTBF, Mean Time Between Failure）来度量；可维护性则通过平均修复时间（MTTR, Mean Time To Repair）来度量。可用性衡量系统在总时间内可以正常使用的时间比例，公式为：A = MTBF / (MTBF + MTTR)。因此，可用性是通过可靠性和可维护性计算得出的比例。例如，99.9999% 的可用性意味着平均每年系统故障修复时间为 32 秒。
 - **分区容错性**（**P**artition tolerance）：当部分节点由于网络故障或通信中断而无法相互联系，形成“网络分区”时，系统仍能够继续正确地提供服务。
 
-:::tip 额外知识
-
-对于分布式系统而言，必须实现分区容错性（P）。因此，CAP 定理实际上要求在可用性（A）和一致性（C）之间进行选择，即在 AP 和 CP 之间权衡取舍。
-:::
-
 由于 CAP 定理已有严格的证明，本节不去探讨为何 CAP 不可兼得，而是直接分析如果舍弃 C、A、P 时所带来的不同影响。
 
 - **放弃分区容忍性（CA without P）**：意味着我们将假设节点之间通信永远是可靠，永远可靠的通信在分布式系统中必定不成立，只要依赖网络共享数据，分区现象就不可避免地存在。如果没有 P（分区容错性），也就谈不上是真正的分布式系统。
 - **放弃可用性（CP without A）**：意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制地延长。在现实中，选择放弃可用性的 CP 系统适用于对数据一致性有严格要求的场景，如金融系统、库存管理系统等。这些应用场景中，数据的一致性和准确性通常比系统的可用性更为重要。
 - **放弃一致性（AP without C）**：意味着在网络分区发生时，节点之间的数据可能会出现不一致。这种情况下，系统会优先保证可用性，而不是一致性。选择放弃一致性的 AP 系统已经成为设计分布式系统的主流选择，因为分区容错性（P）是分布式网络的固有属性，不可避免；而可用性（A）通常是建设分布式系统的目标。如果系统在节点数量增加时可用性降低，则其分布式设计的价值也会受到质疑。除了像银行和证券这样的金融交易服务，这些场景中数据一致性至关重要，通常需要保证一致性而可能接受部分中断之外，大多数系统更倾向于在节点增多时保持高可用性，而不是牺牲可用性以维持一致性。
 
+:::tip 额外知识
+
+对于分布式系统而言，必须实现分区容错性（P）。因此，CAP 定理实际上要求在可用性（A）和一致性（C）之间选择，即在 AP 和 CP 之间权衡取舍。
+:::
+
 从上述分析可以看出，原本事务的主要目的是保证“一致性”。但在分布式环境中，一致性往往不得不成为牺牲的属性，AP 类型的系统反而成为了分布式系统的主流。但无论如何，我们设计系统终究还是要确保操作结果至少在最终交付的时刻是正确的，这个意思是允许数据中间不一致，但应该在输出时被修正过来。
 
 为此，工程师们又重新给一致性下了定义，**将 CAP、ACID 中讨论的一致性（C）称为“强一致性”，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”**。

distributed-transaction/idempotent.md

@@ -1,10 +1,8 @@
 # 5.4 服务幂等性设计
 
-:::tip 什么是幂等性
-幂等性最初是一个数学概念，后来被引入计算机科学中，用来描述某个操作可以安全地重试，即多次执行的结果与单次执行的结果完全一致。
-:::
+幂等性是一个数学概念，后来被引入计算机科学中，用来描述某个操作可以安全地重试，即多次执行的结果与单次执行的结果完全一致。
 
-柔性事务普遍基于“最大努力交付”机制。也就是说，当网络通信失败、节点宕机或者进程崩溃时，采用重复请求的方式来容错。因此，如果某些关键服务不具备幂等性，重复处理可能导致数据不一致或其他风险。例如，在退款接口中，缺乏幂等性可能导致重复退款。
+柔性事务通常基于“最大努力交付”机制，即在网络通信失败、节点宕机或进程崩溃时，通过重复请求来实现容错。因此，如果某些关键服务不具备幂等性，重复请求会导致数据不一致或其他问题。例如，重复请求一个不具备幂等性的退款接口，可能导致重复退款。
 
 接下来，笔者将介绍两种实现系统幂等的方式，供读者参考。
 

network/conntrack.md

@@ -1,6 +1,6 @@
 # 3.3.3 连接跟踪模块 conntrack
 
-conntrack 是 connection track（连接跟踪）的缩写。
+conntrack 是“连接跟踪”（connection track）的缩写。
 
 顾名思义，Linux 内核中的 conntrack 模块是用来跟踪“连接”的。需要注意的是，conntrack 中的“连接”指的是通信双方之间的数据传输连接，不仅跟踪 TCP 连接，还可以跟踪 UDP、ICMP 这样的“连接”。当 Linux 系统收到数据包时，内核中的 conntrack 模块为其新建一个（或标识属于某个）连接记录（或称连接条目），并根据数据包类型更新连接状态（如 NEW、ESTABLISHED 等）。