diff --git a/application-centric/Controller.md b/application-centric/Controller.md
index 7a3706bd..97f17ce6 100644
--- a/application-centric/Controller.md
+++ b/application-centric/Controller.md
@@ -52,6 +52,6 @@ spec:
借助 CRD（自定义资源定义），工程师便可突破 Kubernetes 内置资源的限制，根据需求创建自定义资源类型，例如数据库、CI/CD 流程、消息队列或数字证书等。配合自定义的控制器，便能将特定的业务逻辑、特定的基础设施能力无缝集成到 Kubernetes 中。
-最终，云原生生态圈那些让人兴奋的技术，通过插件、接口、容器设计模式、Mesh 形式，以“声明式管理”为基础下沉至 Kubernetes 中，并通过声明式 API 暴露出来。虽然 Kubernetes 变得越来越复杂，但声明式 API 的好处就在于，它能够在基础设施的复杂度呈指数级增长的同时，保证使用者的交互界面复杂度仅以线性增长。
+最终，云原生生态圈那些让人兴奋的技术，通过插件、接口、容器设计模式、Mesh 形式，以“声明式管理”为基础下沉至 Kubernetes 中，并通过声明式 API 暴露出来。虽然 Kubernetes 的复杂度不断增加，但声明式 API 的优势在于，它能确保在基础设施复杂度指数级增长的同时，用户交互界面的复杂度仅以线性方式增长。否则，Kubernetes 早就成为一个又难学、又难用的系统了。
diff --git a/consensus/Basic-Paxos.md b/consensus/Basic-Paxos.md
index 7e1603bf..2f48c733 100644
--- a/consensus/Basic-Paxos.md
+++ b/consensus/Basic-Paxos.md
@@ -2,6 +2,8 @@
希望你没有对前篇 Paxos 的“复杂”做的铺垫所吓倒，共识问题已经算是一个古老的领域，30 余年间已经有无数简洁直白的视频、论文等资料进行过解读。网络中流传甚广的 Raft 和 Paxos 视频讲解[^1]，即使没有多少技术背景，也能通俗地理解 Paxos。
+接下来，我们先了解 Paxos 基本背景，然后直面 Paxos 算法细节，最后再用具体的例子验证 Paxos 算法。
+
## 1. Paxos 算法背景
在 Paxos 算法中，节点分为下面三种角色：
@@ -73,7 +75,7 @@ Paxos 算法的第二个阶段称“批准阶段”（Accept）。提议者向
**情况一：提案已批准**。如图 6-7 所示，S~1~ 收到客户端的请求，于是 S~1~ 作为提议者，向 S~1~...S~3~ 广播 Prepare(3.1) 消息，决策者 S~1~...S~3~ 没有接受过任何提案，所以接受该提案。接着，S~1~ 广播 Accept(3.1, X) 消息，提案 X 成功被批准。
-在提案 X 被批准后，S~5~ 收到客户端的提案 Y，S~5~ 作为提议者向 S~3~...S~5~ 广播 Prepare(4.5) 消息。对 S~3~ 来说，4.5 比 3.1 大，且已经接受了 X，它回复提案 (3.1, X)。S~5~ 收到 S~3~...S~5~ 的回复后，使用 X 替换自己的 Y，接着进入下批准阶段，广播 Accept(4.5, X) 消息。S~3~...S~5~ 批准提案，最终所有决策者就 X 达成一致。
+在提案 X 被批准后，S~5~ 收到客户端的提案 Y，S~5~ 作为提议者向 S~3~...S~5~ 广播 Prepare(4.5) 消息。对 S~3~ 来说，4.5 比 3.1 大，且已经接受了 X，它回复提案 (3.1, X)。S~5~ 收到 S~3~...S~5~ 的回复后，使用 X 替换自己的 Y，接着进入批准阶段，广播 Accept(4.5, X) 消息。S~3~...S~5~ 批准提案，所有决策者就 X 达成一致。
:::center
diff --git a/container/auto-scaling.md b/container/auto-scaling.md
index 7dce9b44..5272d883 100644
--- a/container/auto-scaling.md
+++ b/container/auto-scaling.md
@@ -4,11 +4,11 @@
## 7.8.1 Pod 水平自动伸缩
-HPA（Horizontal Pod Autoscaler，Pod 水平自动扩缩）是根据工作负载（如 Deployment）的需求自动调整 Pod 副本的数量的机制。
+HPA（Horizontal Pod Autoscaler，Pod 水平自动扩缩）是根据工作负载（如 Deployment）的资源使用情况调整 Pod 副本数量的机制。
HPA 的工作原理简单明了：
-- 当负载较高时，增加 Pod 副本数量；
-- 当负载较低时，减少 Pod 副本数量。
+- 当负荷较高时，增加 Pod 副本数量；
+- 当负荷较低时，减少 Pod 副本数量。
因此，自动伸缩的关键在于准确监控资源使用情况。为此，Kubernetes 提供了 Metrics API，用于获取节点和 Pod 的资源信息。以下是 Metrics API 的响应示例，展示了 CPU 和内存的使用情况。
diff --git a/container/conclusion.md b/container/conclusion.md
index a980c755..f148f19d 100644
--- a/container/conclusion.md
+++ b/container/conclusion.md
@@ -3,7 +3,7 @@
本章，笔者从 Google 内部容器系统演进作为开篇，从网络、计算、存储、调度等方面展开，深入分析了 Kubernetes 的设计原理和应用。希望能让你在学习 Kubernetes 这个复杂而庞大的项目时，抓住其核心主线，理解其设计理念。
在笔者看来，作为基础设施的 Kubernetes，它的设计理念有两个核心：
-- 其一，从 API 到容器运行时的每一层，都为开发者暴露可供扩展的插件机制。通过 CNI 插件把网络功能解耦，让外部的开发社区、厂商参与容器网络的实现；通过 CSI 插件建立了一套庞大的存储生态；通过 Device Plugin 把物理资源的支持扩展到 GPU、FPGA、DPDK、RDMA 等各类异构设备。依托这种开放性设计，Kubernetes 社区出现了成千上万的插件，让运维工程师可以轻松构建出功能强大的基础架构平台。从这一点讲，这也是 CNCF 基于 Kubernetes 能构建出一个庞大生态的原因。所以说，Kubernetes 并不是一个简单的容器编排平台，而是一个分量十足的“接入层”，是云原生时代真真正正的“操作系统”。
-- 其二，在开放性的底层之上，Kubernetes 将接触的方方面面统一抽象为“资源”。所有的“资源”使用 YAML 文件描述，一个 YAML 文件即可表达一个复杂基础设施的最终状态，并且自动地对应用程序进行运维和管理。这种设计**隐藏了底层细节、屏蔽底层差异，以一种友好、一致且跨平台的方式，向业务工程师“输送”底层基础设施能力**，正是 Kubernetes 设计哲学的精髓所在。
+- 其一，从 API 到容器运行时的每一层，都为开发者暴露可供扩展的插件机制。通过 CNI 插件把网络功能解耦，让外部的开发社区、厂商参与容器网络的实现；通过 CSI 插件建立了一套庞大的存储生态；通过设备插件机制把物理资源的支持扩展到 GPU、FPGA、DPDK、RDMA 等各类异构设备。凭借这种开放性设计，Kubernetes 社区涌现出成千上万的插件，帮助运维工程师轻松构建强大的基础设施平台。从这一点讲，这也是 CNCF 基于 Kubernetes 能构建出一个庞大生态的原因。所以说，Kubernetes 并不是一个简单的容器编排平台，而是一个分量十足的“接入层”，是云原生时代真真正正的“操作系统”。
+- 其二，在这一开放性底层之上，Kubernetes 将各类资源统一抽象为“资源”，并通过 YAML 文件描述。这种设计使得一个 YAML 文件即可表达复杂基础设施的最终状态，并自动管理应用程序的运维。Kubernetes 隐藏了底层实现细节，屏蔽了不同平台的差异，以一致、友好、跨平台的方式将底层基础设施能力“输送”给业务工程师，正是它的设计哲学的精髓所在。
接下来，笔者将介绍基于“容器设计模式”的二次创新，也就是近几年热度极高的“服务网格”（ServiceMesh）技术。
\ No newline at end of file
diff --git a/container/kube-scheduler.md b/container/kube-scheduler.md
index dc3228a8..28ced5cf 100644
--- a/container/kube-scheduler.md
+++ b/container/kube-scheduler.md
@@ -30,7 +30,7 @@ Kubernetes 默认调度器（kube-scheduler）双循环调度机制如图 7-36
第二个控制循环是“Scheduling 循环”。其主要逻辑是从调度队列（PriorityQueue）中不断出队一个 Pod，并触发两个核心的调度阶段：预选阶段（图 7-36 中的 Predicates）和优选阶段（图 7-36 中的 Priority）。
-Kubernetes 从 v1.15 版本起，为默认调度器（kube-scheduler）设计了可扩展的机制 —— Scheduling Framework。其主要目的是在调度器生命周期的关键点（如图7-37中的绿色矩形箭头框所示）暴露可扩展接口，允许实现自定义的调度逻辑。这套可扩展的机制是使用标准 Go 语言插件机制实现的，需要按照规范编写 Go 代码，通过静态编译集成进去。所以，它的通用性和前文提到的 CNI、CSI 或者 CRI 无法相提并论。
+Kubernetes 从 v1.15 版本起，为默认调度器（kube-scheduler）设计了可扩展的机制 —— Scheduling Framework。其主要目的是在调度器生命周期的关键点（如图7-37中的绿色矩形箭头框所示）暴露可扩展接口，允许实现自定义的调度逻辑。这套机制基于标准 Go 语言插件机制，需要按照规范编写 Go 代码并进行静态编译集成，其通用性相较于 CNI、CSI 和 CRI 等较为有限。
:::center
图 7-37 Pod 的调度上下文以及调度框架公开的扩展点
diff --git a/distributed-transaction/BASE.md b/distributed-transaction/BASE.md
index c66c73fc..d9ff3836 100644
--- a/distributed-transaction/BASE.md
+++ b/distributed-transaction/BASE.md
@@ -14,7 +14,7 @@ BASE 理论是对 CAP 定理中 AP（可用性和分区容错性）方案的延
Dan Pritchett 在论文中提到的“实现数据一致性的手段”，可以概括为**基于可靠事件队列的事件驱动模式**。该模式的核心在于确保事件可靠投递并避免重复消费。幸运的是，现代消息中间件普遍实现了事件持久化和至少一次投递机制，此外，幂等性的实现也有成熟的解决方案。因此，这些问题如今已经不再构成挑战。
-以一个具体的例子帮助你理解“可靠事件队列”的具体做法。
+接下来，以一个具体的例子帮助你理解“可靠事件队列”的具体做法。
假设有一个电商系统，下单操作依赖于三个服务：支付服务（进行银行扣款）、库存服务（扣减商品库存）和积分服务（为用户增加积分）。下单过程中，我们优先处理最核心、风险最高的服务，按照支付扣款、仓库出库以及为用户增加积分的顺序执行。下单的整个流程如图 5-2 所示。