更新内容

.vuepress/config.js

@@ -202,7 +202,7 @@ export default defineUserConfig({
                 ]
             },
             {
-                text: "第五章：分布式事务",
+                text: "第六章：分布式事务",
                 link: '/distributed-system/distributed-transaction.md',
                 children: [
                     '/distributed-system/BASE.md',

balance/balance7.md

@@ -9,7 +9,6 @@
 
 这种情况下，客户端与七层负载均衡器建立一个 HTTP /2 TCP 连接，后续负载均衡器根据负载均衡策略和两个后端建立了连接。当客户端向负载均衡器发送两个 HTTP/2 流（streams ）时，stream 1 会被发送到 backend-1，而 stream 2 会被发送到 backend-2。因此，即使不同客户端的请求数量差异巨大，这些请求也可以被高效平衡地分发到后端。七层负载均衡具备检测应用层流量的能力，就能做出更多、更明智的决策，也能玩出更多的花样。
 
-七层负载均衡的实现相信读者们已经非常熟悉，最典型的实现莫过于 Nginx，使用 Nginx 七层负载均衡能识别应用层协议，可以通过对 HTTP 头、URL、Cookie 做复杂的逻辑处理，实现更灵活的控制。互联网技术架构中，通常 7 层负载均衡的核心是 Nginx，结合 Lua 插件技术，如 OpenResty，能扩展实现功能丰富且性能较高的网关方案。
 
 ## 4.1.4  是否还需要 L4 负载均衡
 

balance/balancer7-feature.md

@@ -1,6 +1,6 @@
 # 4.4.2 从负载均衡到网关
 
-随着微服务架构、容器编排调度等技术的崛起，现代分布式系统已经越来越动态，这就意味着通过静态文件配置方式早已过时。作为分布式系统的入口，负载均衡器需要提供更多现代化的功能。把这些功能统一前移某一层独立支持，实现 API Gateway as a Service，让各个服务直接接入，在管理平台上管理，可视化配置等等，这样就实现了一个全局的视图统一管理这些功能。
+随着微服务架构、容器编排调度等技术的崛起，现代分布式系统已经越来越动态，这就意味着通过静态文件配置方式早已过时。作为分布式系统的入口，负载均衡器就需要转换角色，不仅仅作为一个代理，而是要承担提供更多现代化的功能。把这些功能统一前移某一层独立支持，实现 API Gateway as a Service，让各个服务直接接入，在管理平台上管理，可视化配置等等，这样就实现了一个全局的视图统一管理这些功能。
 
 而这就是七层负载均衡的升级 -- **网关（API Gateway）**。
 

balance/nginx-conf.md

@@ -1,20 +1,9 @@
-# 4.4.1 Nginx 应用指南
+# 4.4.1 Nginx 代理指南
 
-Nginx 是一款轻量级、高性能 HTTP 和反向代理的 Web 服务器软件。除了可以作为反向代理，Nginx 也可以做负载均衡、正向代理等服务。
+七层负载均衡的实现相信读者们已经非常熟悉，没错，它就是 Nginx。使用 Nginx 七层负载均衡能识别应用层协议，可以通过对 HTTP 头、URL、Cookie 做复杂的逻辑处理，实现更灵活的控制。互联网技术架构中，通常 7 层负载均衡的核心是 Nginx，结合 Lua 插件技术，如 OpenResty，能扩展实现功能丰富且性能较高的网关方案。
 
-Nginx 使用基于事件驱动的架构能够并发处理百万级别的 TCP 连接，高度模块化的设计和自由的许可证（最自由的 2-clause BSD-like license 许可）使得扩展 Nginx 功能的第三方模块层出不穷，而且优秀的设计带来了极佳的稳定性，因此其作为 Web 服务器被广泛应用到大流量的网站上。
 
 
-## Nginx 的工作模式
-
-Nginx 的工作模式是 Master-Worker 模式。
-
-在这种工作模式下，Master 进程的作用读取并验证配置文件 nginx.conf、管理 worker 进程。而 Worker 进程维护一个线程（避免线程切换）处理连接和请求。（Worker 进程的个数由配置文件决定，一般和 CPU 个数相关（降低进程之间上下文切换带来的损耗，配置几个就有几个 Worker 进程），当求到来时，每个 Worker 工作进程都会监听到，通过争抢机制最终只会有一个 Worker 进程会接受并处理。
-
-<div  align="center">
-	<img src="../assets/nginx.png" width = "450"  align=center />
-</div>
-
 ## Nginx 配置指导
 
 Nginx 的主配置文件是 nginx.conf，这个配置文件一共由三部分组成，分别为全局块、events 块和 http 块。

consensus/Paxos.md

@@ -1,17 +1,17 @@
 # 5.2 Paxos 的起源
 
-Paxos 是由 Leslie Lamport[^1] 于 1990 提出的一种基于消息传递且具有高度容错特性的协商共识算法，是当今分布式系统最重要的理论基础，几乎就是“共识”两个字的代名词。
-
-不幸的是 Paxos 论文中采用希腊民主议会的比喻很明显失败了，Lamport 像写小说一样，把一个复杂的数学问题弄成了一篇带有考古色彩的历史小说。根据 Lamport 自己的描述[^2]，三个审稿者都认为该论文虽然不怎么重要但还有些意思，只是应该把其中所有 Paxos 相关的故事背景删掉。Lamport 对这些缺乏幽默感的人感到生气，所以他不打算对论文做任何修改。
+Paxos 是由 Leslie Lamport[^1] 于 1990 提出的一种基于消息传递且具有高度容错特性的协商共识算法，是当今分布式系统最重要的理论基础，几乎就是“共识”两个字的代名词。不幸的是 Paxos 论文中采用希腊民主议会的比喻很明显失败了，Lamport 像写小说一样，把一个复杂的数学问题弄成了一篇带有考古色彩的历史小说。根据 Lamport 自己的描述[^2]，三个审稿者都认为该论文虽然不怎么重要但还有些意思，只是应该把其中所有 Paxos 相关的故事背景删掉。Lamport 对这些缺乏幽默感的人感到生气，所以他不打算对论文做任何修改。
 
 多年后，两个在 SRC(Systems Research Center，DEC 于 1984 年创立，Lamport 也曾在此工作过)工作的人需要为他们正在构建的分布式系统寻找一些合适算法，而 Paxos 恰恰提供了他们想要的。Lamport 就将论文发给他们，他们也没觉得该论文有什么问题。因此，Lamport 觉得论文重新发表的时间到了，《The Part-Time Parliament》[^3] 最终在 1998 年公开发表。
 
-可还是有很多人抱怨这篇论文看不懂，人们只记住了那个奇怪的故事，而不是 Paxos 算法。Lamport 走到哪都要被人抱怨一通。于是他忍无可忍，2001 年使用计算机领域的概念重新描述了一遍算法，并发了论文 《Paxos Made Simple》[^4]，这次论文中一个公式也没有，摘要也只有一句话，满满的都是嘲讽！
+可还是有很多人抱怨这篇论文看不懂，人们只记住了那个奇怪的故事，而不是 Paxos 算法。Lamport 走到哪都要被人抱怨一通。于是他忍无可忍，2001 年使用计算机领域的概念重新描述了一遍算法，并发了论文 《Paxos Made Simple》[^4]。
 
 <div  align="center">
 	<img src="../assets/paxos.png" width = "350"  align=center />
 </div>
 
+是的，你没看错，摘要只有一句话 “The Paxos algorithm, when presented in plain English, is very simple.”！
+
 然而，可能是表述顺序的原因，这篇论文还是非常难以理解，以至于到今天，尽管 Paxos 算法已经面世 30 多年，还是有仍有层出不穷的文章来解释这篇论文（重复造论文），以及在工程上如何实现它。
 
 直到 Google 的 Chubby 横空出世，使用 Paxos 解决了分布式共识的问题，并将其整理成正式的论文发表之后，得益于 Google 的行业影响力，辅以 Chubby 作者 Mike Burrows 那略显夸张但足够吸引眼球的评价推波助澜，Paxos 逐渐被大家熟知和认可。Lamport 凭借他在分布式领域的贡献，最终于 2013 年获得图灵奖。

consensus/summary.md

@@ -2,6 +2,6 @@
 
 微服务架构设计有个服务无状态（stateless）的原则，无状态服务不存储任何信息，这样更容易的横向扩展，实现高可用目标。无状态服务如果需要存储数据时，就往中间件转移。比如持久化的数据往关系数据库存储，缓存的数据往 Redis 存储，消息的接收往 MQ 转移等等。
 
-数据存储到中间件，问题只是被转移，并没有解决，这些带有数据的中间件该如何保证高可用呢？能让分布式集群即使是在部分节点故障、网络延时、网络分割的情况下，整体集群仍具有容错性并最终表现出整体一致的过程，就是我们本章要讨论的话题 -- 分布式共识。
+数据存储到中间件，问题只是被转移，并没有解决，这些带有数据的中间件该如何保证高可用呢？单个节点无论设计都和高可用搭不上边，还是得用分布式多个节点的方式才行。能让分布式集群即使是在部分节点故障、网络延时、网络分割的情况下，整体集群仍具有容错性并最终表现出整体一致的过程，就是我们本章要讨论的话题 -- 分布式共识。
 
-聊分布式共识，避不开 Paxos，不过 Paxos 也因算法复杂而著名，这一节我们就知难而上，从 Paxos 入手，去掉无关干扰，直达分布式系统问题的本质。
+聊分布式共识避不开 Paxos，Paxos 也因算法复杂而著名，这一节我们就知难而上，从 Paxos 入手，去掉无关干扰，直达分布式系统问题的本质。