fix typo

consensus/Paxos-history.md

@@ -1,7 +1,7 @@
 # 6.3.1 Paxos 算法起源
 
 Paxos 算法最初的论文名称为《The Part-Time Parliament》，翻译成中文为“兼职议会”。论文的开头描述了一个虚构的古希腊岛屿考古发现故事。如果不事先说明，你可能不会意识到这是一篇关于分布式的论文。
-:::tip 《The Part-Time Parliament》
+:::tip 《The Part-Time Parliament》节选
 
 公元十世纪初，爱情海上的 Paxos 小岛是一个繁荣的商业中心。随着财富的积累，政治变得愈加复杂，Paxon 的公民用议会制政府取代了古老的神权政治。然而，商业利益高于公民义务，没人愿意将一生投入到议会事务中。因此，Paxon 议会必须在议员频繁进出议会的情况下，保持正常运作……
 :::

consensus/conclusion.md

@@ -1,9 +1,9 @@
 # 6.5 小结
 
-尽管 Paxos 算法已提出几十年，但它为分布式系统中的一致性与容错性问题提供了理论框架，并开创了分布式共识研究的先河。
+尽管 Paxos 算法已提出几十年，但它为分布式系统中的一致性与容错性问题提供了理论框架，开创了分布式共识研究的先河。
 
 Paxos 基于“少数服从多数”（Quorum 机制）原则，通过“请求阶段”和“批准阶段”在不确定环境下，解决了单个“提案”的共识问题。多次运行 Paxos，便可实现一系列“提案”的共识，这就是 Multi-Paxos 的核心思想。Raft 算法在 Multi-Paxos 的基础上，在一致性、安全性和可理解性之间找到平衡，成为业界广泛采用的主流选择。
 
-接下来，再思考一个问题，Raft 算法属于“强领导者”模型，领导者负责所有写入操作，它的写瓶颈就是 Raft 集群的写瓶颈。那么，该如何突破 Raft 集群的写瓶颈呢？
+接下来，再思考一个问题，Raft 算法属于“强领导者”（Strong Leader）模型，领导者负责所有写入操作，它的写瓶颈就是 Raft 集群的写瓶颈。那么，该如何突破 Raft 集群的写瓶颈呢？
 
 一种方法是使用哈希算法将数据划分成多个独立部分（分片）。例如，将一个 100TB 规模数据的系统分成 10 部分，每部分只需处理 10TB。这种根据规则（范围或哈希）将数据分散处理的策略，被称为“分片机制”（Sharding）。分片机制广泛应用于 Prometheus、Elasticsearch 、ClickHouse 等大数据系统（详见本书第九章）。理论上，只要机器数量足够，分片机制就能支持任意规模的数据。

consensus/raft.md

@@ -20,7 +20,7 @@ Paxos 算法的理论描述与实际工程实现之间存在巨大鸿沟，最
 
 2013 年，斯坦福大学的学者 Diego Ongaro 和 John Ousterhout 发表了论文 《In Search of an Understandable Consensus Algorithm》[^1]，提出了 Raft 算法。Raft 论文开篇描述了 Raft 的证明和 Paxos 等价，详细阐述了算法如何实现。也就是说，Raft 天生就是 Paxos 算法的工程化。
 
-:::tip 《In Search of an Understandable Consensus Algorithm》开篇
+:::tip 《In Search of an Understandable Consensus Algorithm》节选
 Raft is a consensus algorithm for managing a replicated log. It produces a result **equivalent to (multi-)Paxos, and it is as efficient as Paxos,** but its structure is different from Paxos;
 :::
 

distributed-transaction/ACID.md

@@ -4,15 +4,15 @@
 
 **这里的一致性指的是，对数据有特定的预期状态，任何数据更改操作必须满足这些状态约束（或者恒等条件）**。例如，处理一个转账业务，其中 A 向 B 转账 ￥50 元。无论是转账前、转账过程中、还是转账完成后，A 和 B 的总金额要求始终保持不变。这意味着数据在整个过程中都保持一致，符合业务约束。
 
-想要达成数据的一致性，需要 3 个方面的努力：
+根据数据库的经典理论，想要达成数据的一致性，需要 3 个方面的努力。
 
 - **原子性（A**tomic）：“原子”通常指不可分解为更小粒度的东西。这里原子性描述的是，客户端发起一个请求（请求包含多个操作）在异常情况下的行为。例如，只完成了一部分写入操作，系统出现故障了（进程崩溃、网络中断、节点宕机）。把多个操作纳入到一个原子事务，万一出现上述故障导致无法完成最终提交时，则中止事务，丢弃或者撤销那些局部修改。
 - **隔离性（I**solation）：
 同时运行的事务不应互相干扰。例如，当一个事务执行多次写入操作时，其他事务应仅能观察到该事务的最终完成结果，而非中间状态。隔离性旨在防止多个事务交叉操作导致的数据不一致问题。
 - **持久性（D**urability）：事务处理完成后，对数据的修改应当是永久性的，即使系统发生故障也不会丢失。在单节点数据库中，持久性意味着数据已写入存储设备（如硬盘或 SSD）。而在分布式数据库中，持久性要求数据成功复制到多个节点。为确保持久性，数据库必须在完成数据复制后，才能确认事务已成功提交。
 
-这也就是常说的事务的“ACID 特性”。值得一提的是，**对于一致性而言，更多的是指数据在应用层的外部表现。应用程序借助数据库提供的原子性、隔离性和持久性，来实现一致性目标。也就是说，A、I、D 是手段，C（Consistency）是 3 者协作的目标，弄到一块完全是为了读起来更顺口。**
+这也就是常说的事务的“ACID 特性”。值得一提的是，**对于一致性而言，更多的是指数据在应用层的外部表现。应用程序借助数据库提供的原子性、隔离性和持久性，来实现一致性目标。也就是说，A、I、D 是手段，C 是 3 者协作的目标，弄到一块完全是为了读起来更顺口。**
 
-当事务仅涉及本地操作时，一致性通常可以通过代码实现起来水到渠成。但倘若事务的操作对象扩展到外部系统，例如跨越多个微服务、数据源甚至数据中心时，再依赖传统的 A、I、D 手段来解决一致性问题变得非常困难。但是，一致性又是在分布式系统中不可回避且必须解决的核心问题。
+当事务仅涉及本地操作时，一致性通常可以通过代码实现起来水到渠成。但倘若事务的操作对象扩展到外部系统，例如跨越多个微服务、数据源甚至数据中心时，再依赖传统的 A、I、D 手段来解决一致性问题变得非常困难。但是，一致性又是在分布式系统中不可回避且必须解决的核心问题。这种情况下，我们就需要转变观念，将一致性视为一个多维度的问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级，在确保代价可承受的前提下，尽可能保障系统的一致性。
 
-这种情况下，我们需要转变观念，将一致性视为一个多维度的问题，而非简单的“是或否”的二元问题。根据不同场景的需求，对一致性的强度进行分级，在确保代价可承受的前提下，尽可能保障系统的一致性。一致性的强弱程度直接影响系统设计权衡。由此，事务从一个具体操作层面的“编程问题”转变成一个需要全局视角的“架构问题”。人们在探索这些架构设计的过程中产生了诸多思路和理论，这其中最为出名的是一致性与可用性的权衡 —— CAP 定理。
+一致性的强弱程度直接影响系统设计权衡。由此，事务从一个具体操作层面的“编程问题”转变成一个需要全局视角的“架构问题”。在探索这些架构设计的过程中，出现了许多思路和理论，其中最著名的便是一致性与可用性之间的权衡 —— 即 CAP 定理。

distributed-transaction/BASE.md

@@ -1,26 +1,25 @@
 # 5.3.1 可靠事件队列
 
-2008 年，eBay 架构师 Dan Pritchett 在 ACM 发表了论文《Base: An Acid Alternative》[^1]。这篇论文中，作者基于实践总结出一种独立于 ACID 之外，通过消息队列和幂等机制来达成数据一致性的技术手段，并提出了“最终一致性”的概念。
+2008 年，eBay 架构师 Dan Pritchett 在 ACM 发表了论文《Base: An Acid Alternative》[^1]，在文中，作者总结了基于实践经验的一种独立于 ACID 的数据一致性技术方案，利用消息队列和幂等机制实现数据一致性，并首次提出了“最终一致性”这一概念。
 
-从论文标题可以看出，最终一致性的概念与 ACID 强一致性对立。因为 ACID 在英文中有的“酸”的含义，这一事务模型的名字刻意拼凑成 BASE（BASE 在英文中有碱的含义）。有酸 vs 碱这个计算机浑然天成的梗加成，《Base: An Acid Alternative》论文广泛传播，BASE 理论和最终一致性的概念也被大家熟悉。
+从论文标题可以看出，最终一致性的概念与 ACID 强一致性对立。因为 ACID 在英文中有的“酸”的含义，这一事务模型的名字刻意拼凑成 BASE（BASE 在英文中有碱的含义）。有酸 vs 碱这个浑然天成的梗加成，《Base: An Acid Alternative》论文被广泛传播，BASE 理论和最终一致性的概念也被大家熟悉。
 
-BASE 是“Basically Available”、“Soft State”和“Eventually Consistent”的缩写，其核心理念为：
+BASE 是“Basically Available”、“Soft State”和“Eventually Consistent”的缩写。
 
-- **基本可用（Basically Available）**：系统保证在大多数情况下能够提供服务，即使某些节点出现故障时，仍尽可能保持可用性。这意味着系统优先保障可用性，而非一致性。
-- **柔性状态（Soft state）**：系统状态允许在一段时间内处于不一致状态。与 ACID 强一致性的要求不同，BASE 允许系统在更新过程处于“柔性”状态，即数据在某些节点上可以暂时不一致。
-- **最终一致性（Eventually consistent）**：最终一致性强调，即使在网络分区或系统故障的情况下，在经过足够的时间和多次数据同步操作后，所有节点的数据一定会一致。
+- **基本可用**（Basically Available）：系统保证在大多数情况下能够提供服务，即使某些节点出现故障时，仍尽可能保持可用性。这意味着系统优先保障可用性，而非一致性。
+- **柔性状态**（Soft state）：系统状态允许在一段时间内处于不一致状态。与 ACID 强一致性的要求不同，BASE 允许系统在更新过程处于“柔性”状态，即数据在某些节点上可以暂时不一致。
+- **最终一致性**（Eventually consistent）：最终一致性强调，即使在网络分区或系统故障的情况下，在经过足够的时间和多次数据同步操作后，所有节点的数据一定会一致。
 
-BASE 理论是对 CAP 定理中 AP（可用性和分区容错性）方案的延伸，强调在分布式系统中即使无法实现强一致性，也可以通过适当的方式使系统最终达到一致性。
 
-Dan Pritchett 在论文中提到的“实现数据一致性的手段”，可以概括为**基于可靠事件队列的事件驱动模式**。该模式的核心在于确保事件可靠投递并避免重复消费。幸运的是，现代消息中间件普遍实现了事件持久化和至少一次投递机制，此外，幂等性的实现也有成熟的解决方案。因此，这些问题如今已经不再构成挑战。
+BASE 理论是对 CAP 定理中 AP（可用性和分区容错性）方案的进一步发展，强调即使无法实现强一致性，分布式系统也可以通过适当的机制最终达到一致性。这个适当的机制可概括为**基于可靠事件队列的事件驱动模式**。
 
 接下来，以一个具体的例子帮助你理解“可靠事件队列”的具体做法。
 
 假设有一个电商系统，下单操作依赖于三个服务：支付服务（进行银行扣款）、库存服务（扣减商品库存）和积分服务（为用户增加积分）。下单过程中，我们优先处理最核心、风险最高的服务，按照支付扣款、仓库出库以及为用户增加积分的顺序执行。下单的整个流程如图 5-2 所示。
 
 :::center
   ![](../assets/BASE.svg)<br/>
-  图 5-2 可靠事件队列模型
+  图 5-2 可靠事件队列事务模型
 :::
 
 首先，用户向商店发送了一个交易请求，如购买一件价值 ￥100 的商品。
@@ -40,7 +39,7 @@ struct Message {
 
 此时，会出现以下几种情况：
 
-- **仓库服务和积分服务顺利完成任务**：这两个服务成功执行了出库和积分操作，并将结果反馈给支付服务。随后，支付服务将消息状态更新为“已完成”，整个事务顺利完成，实现最终一致性。
+- **仓库服务和积分服务顺利完成任务**：这两个服务成功执行了出库和积分操作，并将结果反馈给支付服务。随后，支付服务将消息状态更新为“已完成”，整个事务顺利完成，最终实现一致性。
 - **网络问题导致消息未送达**：如果仓库服务或积分服务因网络问题未收到支付服务的消息，此时，支付服务中的消息状态将保持为“待处理”。消息服务会在每次轮询时继续向未响应的服务节点重复发送消息，直到通信恢复正常。为了确保出库和积分操作仅被执行一次，所有接收消息的服务必须具备幂等性（有关幂等性的设计，详见5.4节）。
 - **服务无法完成操作**：如果仓库服务或积分服务由于某种原因无法完成操作（例如，仓库库存不足），消息服务将持续发送消息，直到操作成功（如库存补充）或通过人工干预终止。