From 10cd62ff33487aa744a359c434a6b2f27b4de990 Mon Sep 17 00:00:00 2001 From: Axlgrep Date: Sun, 5 Jun 2022 15:04:28 +0800 Subject: [PATCH] Update ch9.md --- ch9.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch9.md b/ch9.md index 19b2088..887a6cc 100644 --- a/ch9.md +++ b/ch9.md @@ -451,7 +451,7 @@ CAP 定理的正式定义仅限于很狭隘的范围【30】，它只考虑了 ### 全序广播 -如果你的程序只运行在单个 CPU 核上，那么定义一个操作全序是很容易的：可以简单地就是 CPU 执行这些操作的顺序。但是在分布式系统中，让所有节点对同一个全局操作顺序达成一致可能相当棘手。在上一节中，我们讨论了按时间戳或序列号进行排序，但发现它还不如单主复制给力（如果你使用时间戳排序来实现唯一性约束，就不能容忍任何错误，因为你必须要从每个节点都获取到最新的序列号）。 +如果你的程序只运行在单个 CPU 核上，那么定义一个操作全序是很容易的：可以简单认为就是 CPU 执行这些操作的顺序。但是在分布式系统中，让所有节点对同一个全局操作顺序达成一致可能相当棘手。在上一节中，我们讨论了按时间戳或序列号进行排序，但发现它还不如单主复制给力（如果你使用时间戳排序来实现唯一性约束，就不能容忍任何错误，因为你必须要从每个节点都获取到最新的序列号）。 如前所述，单主复制通过选择一个节点作为主库来确定操作的全序，并在主库的单个 CPU 核上对所有操作进行排序。接下来的挑战是，如果吞吐量超出单个主库的处理能力，这种情况下如何扩展系统；以及，如果主库失效（“[处理节点宕机](ch5.md#处理节点宕机)”），如何处理故障切换。在分布式系统文献中，这个问题被称为 **全序广播（total order broadcast）** 或 **原子广播（atomic broadcast）**[^ix]【25,57,58】。