fix typo

balance/balance4.md

@@ -4,4 +4,4 @@
 
 OSI 模型的下三层（物理层、链路层和网络层）称为媒体层（Media Layer），处理的是数据传输的实际介质和路由，上四层（传输层、会话层、表示层和应用层）称为主机层（Host Layer），处理的是主机间的通信。四层负载均衡器的工作模式，主要工作在第二层（数据链路层，改写 MAC 地址）、第三层（网络层，改写 IP 地址）、第四层（传输层，改写 UDP 或 TCP 的连接端口和连接地址，做一些 NAT 之类的操作）。
 
-既然请求已经到了主机层，自然谈不上什么请求转发，只能算作请求代理。但出于习惯，所有的资料都把它们称为四层负载均衡。笔者继续沿用这种惯例，不论是网络层的 IP 处理还是传输层的 NAT 处理，统称四层负载均衡。
+既然请求已经到了主机层，自然谈不上什么请求转发，只能算作请求代理。但出于习惯，所有的资料都把它们称为四层负载均衡。笔者继续沿用这种惯例，来自客户端的请求，无论是网络层处理，还是在传输层的处理，统称为四层负载均衡处理。

container/CRI.md

@@ -1,6 +1,6 @@
 # 7.4 容器运行时接口的演变
 
-Docker 完全没有预料到：它诞生十多年后，仍然能够再次成为舆论的焦点。事件的起因是 Kubernetes 宣布开始进入废弃 dockershim 支持的倒计时，随后讹传讹被人误以为 Docker 不能再用了。虽说此次事件有众多标题党的推波助澜，但也侧面说明了 Kubernetes 与 Docker 的关系十分微妙。
+Docker 完全没有预料到：它诞生十多年后，仍然能够再次成为舆论的焦点。事件的起因是 Kubernetes 宣布进入废弃 dockershim 支持的倒计时，随后讹传讹被人误以为 Docker 不能再用了。虽说此次事件有众多标题党的推波助澜，但也侧面说明了 Kubernetes 与 Docker 的关系十分微妙。
 
 本节，我们把握这两者关系的变化，从中理解容器运行时规范以及 Kubernetes CRI 容器运行时接口的演变。
 

container/summary.md

@@ -8,9 +8,9 @@
 —— by C.A.R. Hoare[^1]
 :::
 
-以 Docker 为代表的容器引擎，通过镜像封装应用及其依赖，对单体应用的测试、发布和部署流程实现了完美闭环。通过 Docker 封装应用，已经成为开发与运维广泛认可的最佳实践。不过，随着应用从单体向分布式演变，手动管理容器的弊端逐渐显现。想要清除容器在大规模系统应用的障碍，唯有以最恰当的方式，解决资源分配、跨节点通信、弹性扩展等一系列容器编排及部署问题。
+以 Docker 为代表的容器引擎，通过镜像封装应用及其依赖，对单体应用的测试、发布和部署流程实现了完美闭环。通过 Docker 封装应用，已经成为开发与运维广泛认可的最佳实践。不过，随着应用从单体向分布式演变，手动管理容器的弊端逐渐显现。如果要清除容器在大规模系统应用的障碍，只有以最恰当的方式，解决资源分配、跨节点通信、弹性扩展等一系列容器编排及部署问题。
 
-实现容器自动化部署、扩缩等一系列管理操作的系统称之为容器编排系统。过去十年间，Kubernetes 已成为容器编排系统的事实标准，并成为大数据分析、机器学习以及在线服务领域被广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，也演变为当今最复杂的软件系统之一。
+实现容器自动化部署、扩缩等一系列管理操作的系统称之为容器编排系统。过去十年间，Kubernetes 已成为容器编排系统的事实标准，并成为大数据分析、机器学习以及在线服务领域被广泛认可的最佳技术底座。然而，Kubernetes 在解决复杂问题的同时，本身也逐渐演变成当今最复杂的软件系统之一。
 
 目前，包括官方文档在内的大多数 Kubernetes 资料都聚焦于“怎么做”，鲜有对“为什么这么做”进行解释。自 2015 年起，Google 陆续发布了《Borg, Omega, and Kubernetes》及《Large-scale cluster management at Google with Borg》等论文，分享了开发和运维 Borg、Omega 和 Kubernetes 系统的经验与教训。本章，笔者将从这几篇论文着手，介绍 Google 内部容器系统是怎么演变的。汲取背后的设计思想后，再来深入理解 Kubernetes 关于容器在资源、网络、存储、调度等方面的设计原理和应用。本章内容安排如图 7-0 所示。
 

distributed-transaction/ACID.md

@@ -6,13 +6,13 @@
 
 想要达成数据的一致性，需要 3 个方面的努力：
 
-- **原子性（A**tomic）：通常，原子是指不可分解为更小粒度的东西。指的是事务中所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
+- **原子性（A**tomic）：通常，原子是指不可分解为更小粒度的东西。这里原子性描述的是，客户端发起一个包含多个写操作请求时可能发生的情况，例如只完成了一部分写入操作，系统出现故障了（进程崩溃、网络中断、节点宕机）；把多个写入操作纳入到一个原子事务，万一出现上述故障导致无法完成最终提交时，则事务中止，且数据库必须丢弃或者撤销那些局部修改。
 - **隔离性（I**solation）：同时运行的事务不应该互相干扰。例如，如果某个事物进行多次写入，则另一个事物观察到的应该是其全部完成的结果，而不应该看到中间部分结果。隔离性可以防止多个事务并发执行时，由于交叉执行而导致数据的不一致。
 - **持久性（D**urability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。对于单节点的数据库，持久性意味着数据已经被写入存储设备，如硬盘或者 SSD。对于分布式数据库，持久性则意味着数据已成功复制到多个节点。为了实现持久性保证，数据库必须等到复制完成才能报告事务成功提交。
 
 这也就是常说的事务的“ACID 特性”。值得一提的是，对于一致性而言，A、I、D 是手段，C（Consistency）是 3 者协作的目标，弄到一块完全是为了读起来顺口。
 
 
-当事务的影响范围局限于本地系统时，一致性通过编码实现起来水到渠成。但倘若事务修改的对象影响涉及外部，如跨越不同的微服务、跨越不同的数据源，甚至跨越多个数据中心时，一致性问题通常很难再使用 A、I、D 来解决。但是，一致性又是分布式系统中必然会遇到且必须要解决的问题。这种情况下，我们需要转变观念，将一致性视为一个多元问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级讨论，在确保代价可承受的前提下，最大程度地保障系统的一致性。
+当事务中修改的操作局限在本地时，一致性通过编码实现起来水到渠成。但倘若事务修改的对象影响涉及外部，如跨越不同的微服务、跨越不同的数据源，甚至跨越多个数据中心时，一致性问题通常很难再使用 A、I、D 来解决。但是，一致性又是分布式系统中必然会遇到且必须要解决的问题。这种情况下，我们需要转变观念，将一致性视为一个多元问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级讨论，在确保代价可承受的前提下，最大程度地保障系统的一致性。
 
 一致性的强弱程度关乎系统设计权衡。由此，事务处理从一个具体操作上的“编程问题”转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，这其中最为出名的是一致性与可用性的权衡定理 —— CAP 定理。

distributed-transaction/summary.md

@@ -9,9 +9,9 @@
 :::
 
 
-提及事务（transaction），最早指本地事务，也就是在本地对某个数据库的多个读、写操作捆绑在一起形成一个操作单元。该操作单元作为一个执行整体要么成功（提交），要失败（中止或回滚），从而保证数据在极端情况下（节点宕机、网络通信失败等）的一致性。不过，分布式系统盛行之后，事务处理的范畴不再局限于数据库内，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性处理等等，都需要用到事务的机制进行处理。
+提及事务（transaction），最早指本地事务，也就是在本地对某个数据库的多个读、写操作捆绑在一起形成一个操作单元。该操作单元作为一个执行整体要么成功（提交），要失败（中止或回滚），从而保证数据在极端情况下（进程崩溃、网络中断、节点宕机）的一致性。不过，分布式系统盛行之后，事务处理的范畴不再局限于数据库内，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性处理等等，都需要用到事务的机制进行处理。
 
-如果对一致性要求局限于本地时，如何实现事务仅仅是个编码问题。但若操作涉及了多个网络节点，如何保证分布式系统下数据一致性便成了架构设计问题。2000 年以前，人们曾经希望基于两阶段提交（2PC）的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，彻底掌握各个分布式事务模型。
+当事务中修改的操作局限在本地时，如何实现事务仅仅是个编码问题。但若事务中的修改操作涉及了多个网络节点，如何保证分布式系统下数据一致性便成了架构设计问题。2000 年以前，人们曾经希望基于两阶段提交（2PC）的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，彻底掌握各个分布式事务模型。
 
 :::center
   ![](../assets/distributed-transaction.png)

network/DPDK.md

@@ -2,7 +2,7 @@
 
 2010 年，由 Intel 领导的 DPDK（Data Plane Development Kit，数据平面开发套件）实现了一套基于“内核旁路”思想的高性能网络应用开发解决方案，并逐渐成为了独树一帜的成熟技术体系。
 
-起初，DPDK 实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，这使得 DPDK 支持更多的处理器和网卡。例如，处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器；网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
+起初，DPDK 实际上是 Intel 为了卖自家的硬件，针对 Intel 处理器和网卡开发的一款高性能的网络驱动组件。DPDK 开源之后，越来越多的厂商参与进来贡献代码，这使得 DPDK 开始支持更多的处理器和网卡。例如，处理器不仅支持 Intel，还支持 AMD、ARM 等厂商的处理器；网卡支持的范围也包括 Intel 网卡、Mellanox 网卡、ARM 集成网卡等。
 
 图 3-6 展示了 DPDK 与传统内核网络的区别。在 Linux 系统中，位于用户空间的 DPDK Lib 和 APP 被视为一个普通的用户进程，其编译、连接和加载方式和普通程序没什么区别。但两者网络数据包在 Linux 系统中的传输路径完全不同：
 
@@ -15,11 +15,13 @@
 :::
 
 
-图 3-7 展示了 DPVS（基于 DPDK 实现的四层负载均衡器）与 LVS（基于 Linux 内核网络实现的四层负载均衡器）的性能对比。从每秒转发数据包数量（Packet Per Second，PPS）指标来看，DPVS 的表现比 LVS 高出 300%。对于海量用户规模的互联网应用来说，动辄需要部署数千、甚至数万台服务器，如果能将单机性能提升十倍甚至百倍，无论是从硬件投入还是运营成本上来看，都能带来非常可观的成本削减。这样的技术变革带来的潜在效益，无疑非常诱人。
+图 3-7 展示了 DPVS（基于 DPDK 实现的四层负载均衡器）与 LVS（基于 Linux 内核网络实现的四层负载均衡器）的性能对比。根据每秒转发数据包数量（Packet Per Second，PPS）指标来看，DPVS 的表现比 LVS 高出 300%。
 
 :::center
   ![](../assets/dpvs-performance.png)<br/>
  图 3-7 DPVS 与 LVS 的 PPS 性能指标对比 [图片来源](https://github.com/iqiyi/dpvs)
 :::
 
-DPDK 属于硬件厂商主导的“内核旁路”技术。接下来，笔者再介绍由社区开发者主导的另一类“内核旁路”技术。
+对于海量用户规模的互联网应用来说，动辄需要部署数千、甚至数万台服务器，如果能将单机性能提升十倍甚至百倍，无论是从硬件投入还是运营成本上来看，都能带来非常可观的成本削减。这样的技术变革带来的潜在效益，无疑非常诱人。
+
+根据本节的前述来看，DPDK 属于硬件厂商主导的“内核旁路”技术。接下来，笔者再介绍由社区开发者主导的另一类“内核旁路”技术。