單機很乾脆：要嘛能跑，要嘛不能跑

在一台電腦上寫程式，行為通常很好預測。硬體正常時，同樣的操作永遠產生同樣的結果，這叫 確定性（deterministic）。 這其實是刻意設計出來的：一旦內部出錯，電腦寧可直接當掉（想想那個藍白當機畫面），也不要回傳一個看起來正常、其實是錯的結果——因為錯誤的結果遠比完全停擺更難處理。

但當軟體跑在多台用網路連起來的電腦上，這個理想模型就破滅了。你不再活在數學般完美的世界裡，必須面對物理現實的混亂：電力可能忽然中斷、機櫃可能被誤觸斷電、甚至真的發生過有人開車撞進機房的空調系統。

當系統中有些部分用不可預期的方式壞掉、其他部分卻運作良好，這種現象就叫 部分失效（partial failure）。 最麻煩的地方在於它是非確定性的：只要牽涉到多個節點與網路，同一件事有時成功、有時莫名其妙失敗，你甚至無法確知它到底成功了沒——因為訊息在網路上跑的時間本身就無法預測。

直接讀原文：部分失效是什麼

這幾句話，是整章、甚至整個「分散式系統很難搞」主題的起點。原文很平實，但每個字都是重點。

兩種哲學：一壞就全停，還是撐著繼續跑？

面對「東西總會壞」這個事實，工程史上出現過兩種完全相反的應對哲學。書裡用超級電腦和雲端運算這兩個極端，把差異拉得很清楚。

親眼看一次：一個節點默默壞掉，其他人完全不知道

「部分失效」聽起來抽象，看一次動畫就懂了。叢集裡有三個節點在正常服務使用者，其中一個忽然靜默故障——沒有錯誤訊息、沒有警報，就是不再回應了。按「下一步」看接下來發生什麼。

用不可靠的零件，蓋出可靠的系統

你可能直覺覺得，系統的可靠度頂多等於它最弱的那個零件——木桶理論，最短的那塊木板決定水位。但書裡告訴我們：這其實不對。從一個較不可靠的底層，建造出更可靠的系統，是計算領域一個古老且可行的想法。

小試身手

部分失效、兩種故障哲學、還有用不可靠零件蓋可靠系統——來檢查一下有沒有抓到重點。

除了網路，機器之間什麼都不共享

本書談的分散式系統，骨子裡是 Shared-nothing 系統 ——一堆機器靠網路連起來，每台有自己的記憶體與磁碟，一台機器無法直接存取另一台的記憶體或磁碟，只能透過網路發送請求。

而網際網路、大多數資料中心內網，都是 非同步封包網路 ——一個節點可以送封包給另一個節點，但網路不保證何時到達、甚至是否會到達。

當你送出請求並期待回應時，可能發生下面這些事：

直接讀原文：這些情況「無法區分」

這是本章最核心的一段話——書用很平靜的語氣，講出一個讓人有點不安的事實。

跑一遍看看：三種完全不同的命運，同一種等待

按「下一步」，看同一個請求送出去之後，可能走向哪三種不同結局——而對客戶端來說，這三種結局的「外部症狀」完全一樣：一直等，然後 timeout。

分不清，就要設計成「能容忍」

既然無法區分，工程上的策略不是「想辦法分清楚」，而是換一個問題：假設分不清，系統該怎麼設計才不會出事？

def transfer(request_id, from_acct, to_acct, amount):
    if already_processed(request_id):
        return "OK（已處理過，直接回成功）"
    do_transfer(from_acct, to_acct, amount)
    mark_processed(request_id)
    return "OK"

延遲為什麼會忽快忽慢？答案是「排隊」

就像開車塞車，網路封包延遲的變異多半來自 排隊（queueing）：

Timeout 該設多長？敲鄰居家的門告訴你答案

如果 timeout 是判斷故障唯一可靠的手段，那它該設多長，就是一個真正棘手的問題——太長、太短都有代價。

小試身手

這一路看下來，網路不可靠的核心邏輯有兩層：分不清原因、只能猜測。來檢查一下有沒有抓到重點。

電腦裡其實住著兩種鐘

網路不可靠已經夠麻煩了，現在再加一個壞消息：每台機器量時間的方式，也不可靠。現代電腦至少有兩種鐘，雖然都叫「鐘」，用途卻完全不一樣——搞混，就會出大問題。

直接讀原文：兩種鐘的官方定義

書裡用一句話點出關鍵區分——量時間點，跟量時間長度，是兩件完全不同的事。

同步這件事，遠不如你以為的可靠

單調鐘不需同步；但時間日曆鐘得靠外部來源校正才有用，最常見的是 NTP。 可惜這套機制一堆地方會出錯：

親眼看一次：時鐘偏差怎麼默默吃掉一筆寫入

現在把前兩格的教訓兌現成一個真實會發生的悲劇。節點 A 的時鐘比較快、節點 B 的時鐘比較慢——B 上「比較晚實際發生」的寫入，因為時間戳反而比 A 那筆「比較早發生」的寫入更小，用 LWW 比較時間戳時就會被誤判成舊資料，直接被丟棄——而且沒有任何錯誤訊息。按「下一步」看它怎麼發生。

更陰險的陷阱：程式可能突然被按下暫停鍵

時鐘偏差已經夠煩，還有一種更隱形的敵人——你的程式可能在執行到一半時，被整個世界按下暫停鍵，睡了幾秒甚至幾分鐘，醒來卻完全不知道自己睡了多久。

會讓行程突然暫停的原因，多到嚇人：程式語言執行環境（如 JVM）的 垃圾回收 garbage collection 有時需要「stop-the-world」暫停所有執行緒，曾經長達數分鐘；虛擬機可能在任意時刻被掛起或搬移；作業系統的 context switch、磁碟 I/O、換頁，都可能讓執行緒卡住一段時間。

if (lease.expiryTimeMillis - System.currentTimeMillis() < 10000) {
    lease = lease.renew();
}
if (lease.isValid()) {
    process(request);   // 若這之前被暫停 15 秒，租約恐已過期！
}

小試身手

時鐘的兩種身分、還有 LWW 默默丟資料的陷阱，來檢查一下有沒有記牢。

一個節點說了不算

想像一個節點正經歷一分鐘的 stop-the-world GC 暫停。其他節點等了又等、越等越不耐煩，最終宣告它死亡、把它「抬上靈車」。等 GC 結束，這個節點的執行緒像什麼都沒發生一樣繼續跑——它壓根不知道自己被宣告死亡，從它的角度，幾乎沒過多少時間。

這些故事的寓意只有一句話：一個節點無法完全信任自己對情勢的判斷。分散式系統不能只依賴單一節點，因為任何一個節點都可能隨時失效，讓系統卡住、無法恢復。

正因如此，許多分散式演算法都依賴 quorum（法定人數） ——也就是節點間的投票：決策需要幾個節點的最少票數才算數，藉此降低對任何單一節點的依賴。這也包括「宣告某節點死亡」這件事本身——如果一個 quorum 宣告某節點死亡，它就必須被當作死的，即使它自己覺得還很健康，也得乖乖退位。

直接讀原文：Fencing Token 到底怎麼運作

「自認是老大」跟「真的是老大」中間，隔著一個 quorum。書裡用一個具體機制，把這句話落實成程式碼可以檢查的東西。

跑一遍：殭屍領導者 A 想寫入，會發生什麼事

下面把書中 Figure 8-5 的情境變成一個可以互動的小動畫：舊領導者 A 拿了 token 33，暫停後醒來還想寫入——看共享儲存怎麼擋下它。按「下一步」開始。

如果節點不只是慢，而是會「說謊」呢？

Fencing token 能擋下「不小心」犯錯的節點（還沒發現自己租約已過期）。但整本書到目前為止，其實一直悄悄假設著一件事：節點是 不可靠但誠實（unreliable but honest） 的——它們可能很慢、不回應、狀態過時，但只要回應，就是說真話。

但如果節點可能故意送出任意錯誤或損毀的回應（例如謊稱自己收到了某訊息，其實根本沒收到）呢？這種行為稱為 拜占庭故障（Byzantine fault） ，而在這種互不信任的環境下要達成共識，就是知名的「拜占庭將軍問題」——n 位將軍要達成共識，但其中有些叛徒會送假訊息企圖誤導他人，而且事先不知道誰是叛徒。能在這種條件下仍正確運作的系統，稱為 拜占庭容錯（Byzantine fault-tolerant） 。

系統模型：先講清楚規則，才能談對錯

分散式演算法不該過度依賴特定硬體與軟體的細節，所以我們要先形式化「預期會發生哪些故障」——這就是 系統模型（system model） 。時序假設上有三種：同步模型假設網路延遲、行程暫停、時鐘誤差都有固定上限（不切實際）； 部分同步模型 假設系統多數時候良好、但偶爾會超出界限（最貼近現實）；非同步模型則完全不能做任何時序假設，甚至沒有時鐘、不能用 timeout。書中認為，部分同步模型加上 crash-recovery 故障通常最有用、最貼近現實。

有了系統模型，我們才能定義演算法「正確」是什麼意思——透過區分兩種性質：

小試身手

Quorum、fencing token、安全性與活性——來檢查一下有沒有記牢。