From f3810ebf68a5ec70c3be9e38843b8042f3fcd28c Mon Sep 17 00:00:00 2001 From: isno Date: Fri, 7 Feb 2025 14:12:58 +0800 Subject: [PATCH] fix typo --- consensus/Paxos-history.md | 2 +- consensus/Paxos.md | 2 +- consensus/consensus.md | 2 +- consensus/raft.md | 2 +- distributed-transaction/CAP.md | 2 +- distributed-transaction/TCC.md | 2 +- distributed-transaction/summary.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/consensus/Paxos-history.md b/consensus/Paxos-history.md index c75f835f..4f93c194 100644 --- a/consensus/Paxos-history.md +++ b/consensus/Paxos-history.md @@ -1,6 +1,6 @@ # 6.3.1 Paxos 算法起源 -Paxos 算法最初的论文名称为《The Part-Time Parliament》，翻译成中文为“兼职议会”。论文的开头描述了一个虚构的古希腊岛屿考古发现故事。如果不事先说明，你可能不会意识到这是一篇关于分布式的论文。 +Paxos 算法最初的论文名称为《The Part-Time Parliament》，翻译成中文为《兼职议会》。论文的开头描述了一个虚构的古希腊岛屿考古发现故事。如果不事先说明，你可能不会意识到这是一篇关于分布式的论文。 :::tip 《The Part-Time Parliament》节选 公元十世纪初，爱情海上的 Paxos 小岛是一个繁荣的商业中心。随着财富的积累，政治变得愈加复杂，Paxon 的公民用议会制政府取代了古老的神权政治。然而，商业利益高于公民义务，没人愿意将一生投入到议会事务中。因此，Paxon 议会必须在议员频繁进出议会的情况下，保持正常运作…… diff --git a/consensus/Paxos.md b/consensus/Paxos.md index 337e9784..f8e89d32 100644 --- a/consensus/Paxos.md +++ b/consensus/Paxos.md @@ -2,6 +2,6 @@ Paxos 算法由 Leslie Lamport[^1] 于 1990 年提出，是一种基于消息传递、具备高度容错特性的共识算法。该算法是当今分布式系统最重要的理论基础，几乎就是“共识系统”的代名词。 -Paxos 算法因复杂广为人知，围绕它发生过许多有趣的故事，这些已成为人们津津乐道的一段轶事。直接切入 Paxos 算法未免望文生畏，我们不妨从这段轶事开始学习 Paxos 算法之旅。 +Paxos 算法因其复杂广为人知，围绕它发生过许多有趣的故事，这些已成为人们津津乐道的一段轶事。直接切入 Paxos 算法未免望文生畏，我们不妨从这段轶事开始学习 Paxos 算法之旅。 [^1]: Lamport 在分布式系统理论方面有非常多的成就，比如 Lamport 时钟、拜占庭将军问题、Paxos 算法等等。除了计算机领域之外，其他领域的无数科研工作者也要成天和 Lamport 开发的一套软件打交道，目前科研行业应用最广泛的论文排版系统 —— LaTeX (名字中的 La 就是指 Lamport) \ No newline at end of file diff --git a/consensus/consensus.md b/consensus/consensus.md index 10ac87fb..19231be8 100644 --- a/consensus/consensus.md +++ b/consensus/consensus.md @@ -5,7 +5,7 @@ - **共识**（Consensus）：指所有节点就某项操作（如选主、原子事务提交、日志复制、分布式锁管理等）达成一致的实现过程。 - **一致性**（Consistency）：描述多个节点的数据是否保持一致，关注数据最终达到稳定状态的结果。 -本书第五章介绍的 CAP 定理中的 C 和数据库 ACID 模型中的 C 描述的是数据“一致性”属性。而 Paxos、Raft 或者 ZAB 等算法研究的是如何达成一致。因此，将 Paxos 等算法归类到“共识算法”更准确。 +本书第五章介绍的 CAP 定理中的 C 和数据库 ACID 模型中的 C 描述的是数据“一致性”属性。而 Paxos、Raft 或者 ZAB 等算法研究的是如何达成一致。因此，将 Paxos 等算法归类为“共识算法”更准确。 在分布式系统中，节点故障是不可避免的，但部分节点故障不应该影响系统整体状态。通过增加节点数量，依据“少数服从多数”原则，只要多数节点（至少 $\mathit{N/2+1}$）达成一致，其状态即可代表整个系统。这种依赖多数节点实现容错的机制称为 Quorum 机制。 diff --git a/consensus/raft.md b/consensus/raft.md index d94499a4..47f4f472 100644 --- a/consensus/raft.md +++ b/consensus/raft.md @@ -1,7 +1,7 @@ # 6.4 Raft 算法 :::tip 额外知识 -Raft 是由 Re{liable|plicated|dundant} And Fault-Tolerant 组合起来的单词，意思是可靠、复制、冗余和容错。同时，Raft 在英文有“筏”的含义，隐喻一艘帮助你逃离 Paxos 小岛的救生筏。 +Raft 是 Re{liable|plicated|dundant} And Fault-Tolerant，即可靠、复制、冗余和容错，组合起来的单词。同时，Raft 在英文有“筏”的含义，隐喻一艘帮助你逃离 Paxos 小岛的救生筏。 ::: 不可否认，Paxos 是一个划时代的共识算法。 diff --git a/distributed-transaction/CAP.md b/distributed-transaction/CAP.md index f96de8a3..ad18c6cf 100644 --- a/distributed-transaction/CAP.md +++ b/distributed-transaction/CAP.md @@ -30,7 +30,7 @@ CAP 定理描述的是**一个分布式系统中，涉及共享数据问题时 但无论如何，我们设计系统终究还是要确保操作结果至少在最终交付的时刻是正确的，这个意思是允许数据中间不一致，但应该在输出时被修正过来。为此，工程师们又重新给一致性下了定义，**将 CAP、ACID 中讨论的一致性（C）称为“强一致性”，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”**。不过，若只是单纯地谈论“弱一致性”，通常意味着不保证一致性。在弱一致性中，工程师们进一步总结出了一种较强的特例，称为“最终一致性”（Eventual Consistency），它由 eBay 的系统架构师 Dan Pritchett 在 BASE 理论中提出。 :::tip 额外知识 -ACID 在英文中有的“酸”的含义，强调强一致性。BASE 在英文中有“碱”的含义，强调放弃强一致性保证可用性。酸 vs 碱衍生出 AP 型可用性架构和 CP 型强一致性架构。所以，CAP 理论又被戏称度量分布式系统的“Ph试纸”。 +ACID 在英文中有的“酸”的含义，强调强一致性。BASE 在英文中有“碱”的含义，强调放弃强一致性保证可用性。酸 vs 碱衍生出 AP 型可用性架构和 CP 型强一致性架构。所以，CAP 理论又被戏称度量分布式系统的“ph试纸”。 ::: diff --git a/distributed-transaction/TCC.md b/distributed-transaction/TCC.md index 1c7c1497..eabe6f46 100644 --- a/distributed-transaction/TCC.md +++ b/distributed-transaction/TCC.md @@ -25,7 +25,7 @@ TCC（Try、Confirm、Cancel）事务模型源自 Pat Helland 在论文《Life b - 支付服务：扣除冻结的 100 元。 - 仓库服务：标记冻结的库存为出库状态，并扣减库存。 -3. Cancel 阶：如果 Try 阶段任何一方反馈失败，将事务日志状态更新为 Cancel，进入 Cancel 阶段： +3. Cancel 阶段：如果 Try 阶段任何一方反馈失败，将事务日志状态更新为 Cancel，进入 Cancel 阶段： - 支付服务：释放被冻结的 100 元。 - 仓库服务：释放被冻结的库存。 diff --git a/distributed-transaction/summary.md b/distributed-transaction/summary.md index 093804de..f8a23d06 100644 --- a/distributed-transaction/summary.md +++ b/distributed-transaction/summary.md @@ -9,7 +9,7 @@ ::: -事务（transaction）最早指本地事务，也就是对数据库的多个读写操作捆绑为一个操作单元。该操作单元作为一个执行整体要么全部成功、要么全部中止，从而保证某些极端情况下（进程崩溃、网络中断、节点宕机）数据一致性。随着分布式系统的广泛应用，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性保证等等，都需要用到事务的机制进行处理。 +事务（transaction）最早指本地事务，也就是对数据库的多个读写操作捆绑为一个操作单元。该操作单元作为一个执行整体要么全部成功，要么全部中止，从而保证某些极端情况下（进程崩溃、网络中断、节点宕机）数据一致性。随着分布式系统的广泛应用，所有需要保证数据一致性的应用场景，包括但不限于缓存、消息队列、存储、微服务架构之下的数据一致性保证等等，都需要用到事务的机制进行处理。 在单体系统时代，如何实现事务仅仅是个编码问题。但在分布式系统时代，事务操作跨越了多个节点，保证多个节点间的数据一致性便成了架构设计问题。2000 年以前，人们曾经希望基于“两阶段提交”（2PC, Two-Phase Commit Protocol）[^2]的事务机制，也能在现代分布式系统中良好运行，但这个愿望被 CAP 定理粉碎。本章，我们深入理解分布式环境下数据一致性和可用性的矛盾，掌握各个分布式事务模型原理。