概念地圖・FLP 異步共識不可能
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：系統
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
FLP 異步共識不可能：等不到的保證
出貨確認鈕停在等待中，分級包裝中心的人一直看著同一張單：另一台系統究竟停了，還是回覆還在路上？FLP 定理把這段疑惑推到保證的邊界：在完全異步、確定性且容許一個節點停止的模型中，任何守住共識安全要求的協定，都存在合法而永不決定的執行。它問的是保證能開多滿——連極端的訊息時序，也要算進承諾裡。
共識保證與系統假設攤開看
先把「決定什麼」和「何時決定」拆成獨立承諾。圖中的 A、B 互通訊息，仍缺少能判明 C 狀態的資訊。
| 項目 | 要求或前提 | 讀圖時要留意 |
|---|---|---|
| 協議性 | 已決定的節點對同一問題給出相同值 | 放行值不能一邊是 0、一邊是 1 |
| 有效性 | 通常要求決定值符合提案，例如全員提出同一值時就決定該值 | 原論文採較弱的非平凡要求：0 與 1 都各有可能成為結果 |
| 終止 | 每個合法執行都會產生決定 | FLP 找得到永不產生決定的合法執行 |
| 完全異步 | 處理速度與訊息延遲沒有已知時間上界 | 任何有限等待都容得下「還沒到」的解釋 |
| 確定性與停止故障 | 相同狀態及所收訊息決定下一步，容許最多一個節點永久停止 | 故障節點沒有偽造或惡意傳話 |
| 可靠通道 | 送給非故障節點的訊息最終會被收到 | 最終送達的承諾沒有附上期限 |
把程式永遠寫成回覆 0，就避開了真正的選擇，原論文的非平凡要求會排除這種做法。有效性採更強的常見版本，仍落在這個不可能性結果涵蓋的範圍。定理來源是 Fischer、Lynch、Paterson 的 1985 年論文；原文的終止要求甚至只要求某個節點作出決定——這個較弱承諾也保不住所有合法執行。
先問系統願意保證到哪裡
一、把一致結果與最終進展分開描述。分級包裝中心的資訊同仁說「資料會一致」，現場還需要知道出貨鈕何時有結果。可以先寫兩份驗收條件：同一批次永遠不出現相反的已決定放行值，以及在指定運作條件下會完成決定。前一份檢查衝突，後一份追問進度——「還在等」也要被記錄。自問：我是否分別寫清楚結果一致與最終進展的要求？
二、找出時間上界來自哪個假設。倉內操作員等著貼出貨標籤，供應商說超時就重選協調者。接著要問：網路穩定多久後，選舉與傳話才有足夠時間完成？若這句依賴某段穩定期，就把條件列進系統承諾。計時器響了，只表示本次等待超過門檻——C 的真實狀態還有兩種可能。自問：我的完成期限，靠哪一項處理速度或訊息傳遞假設支撐？
三、明確安排外部處置與可回復狀態。批次卡在待決時，值班人員可以暫緩裝車、聯絡買方、保留棧板識別碼。這些動作需要負責人與恢復入口；手動例外則要另留對帳紀錄，免得 C 回來後又重做一次放行。把現場動作寫完整——營運仍然要過這一天。自問：超時之後由誰處置，留下什麼狀態，恢復時如何對帳？
分級包裝的數位放行，走一遍
底下這家台灣中部的分級包裝中心，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。
- 先界定同一道決定：A 是訂單服務、B 是庫存服務、C 是放行服務。假設三個服務用確定性共識，為同一批次決定放行值 0 或 1；業務另外定義哪些提案合格。這裡只拆解共識部分，完整交易與原子提交還有自己的規則。先把題目縮到同一個值
- 看見等待中的兩種可能：A、B 已交換手上資訊，C 的回覆仍未出現。上幅代表 C 已停止；下幅代表 C 繼續運作，回覆被延遲。觀察線以前，A、B 的紀錄相同——工作人員重看同一張畫面，也沒有多出新證據。刷新畫面不會補齊消息
- 把批次留在待決：畫面顯示「待決」，保留批次編號、目前收到的訊息與最後操作。值班主管暫緩這批裝車，通知既定聯絡窗口；尚未有決定的欄位保留原狀。待決也有明確的現場動作
- 讓恢復有路可走：C 的回覆到達或服務恢復後，依協定繼續處理，再檢查這批貨是否仍在待出區。任何人工例外都走獨立對帳程序，核對批次、貨物與操作紀錄。這是業務安排——它沒有替原先的異步模型增加終止保證。人工按鈕也要留下帳
這個場景值得記住的接縫，是數位狀態與實體貨物各有自己的進度。服務仍未決定時，棧板可以先被安置，客戶可以先收到暫緩通知，下一班人員也可以接手同一批次。只要把「待決」藏成轉圈圈，這些安排就會落到操作員口頭傳話。兩幅時序呈現的是一段有限觀察；不能從一次等 C 直接推出整個定理，完整證明還得展示如何持續維持未定的雙價狀態，同時讓合法執行條件成立。以上為說明結構用的示意情境，僅供理解框架之用。
無限等待的結論有多遠
- 存在壞執行，留下的是保證的缺口。FLP 的量詞是「任何符合條件的協定，都存在某個不終止的合法執行」。日常網路常有足夠穩定的時段，系統因此可能順利完成大量工作。拿定理宣稱每次共識都會失敗，會把工程上的成功一起抹掉——真正要問的是，承諾涵蓋哪些執行條件。
- 可靠與延遲必須放在同一句承諾裡。訊息可以被拖得很久，送給非故障節點的訊息仍須最終收到。無限不終止執行靠的是精心安排每一步與傳遞時機，並持續保留尚未決定的可能性。把某封訊息永久丟掉當成整個證明，便離開了這裡的可靠通道設定——這個區別直接影響故障測試怎麼做。
- 改假設，就要重新讀保證。隨機化可把終止改成機率性承諾；最終同步則假定系統在某個時刻後有足夠的處理及通訊時間界限。這些方向讓協定有機會取得更實用的進展保證。評估方案時，把新增假設和承諾一起帶走——它們也都有各自適用的故障模型與條件。
用痛點的眼光認領等待
服務還在等待，客戶的收貨安排已經往前走了。
P.A.I.N. 追問的痛，會落在那通不知道怎麼回覆的電話上。分級包裝中心若只改善按鈕轉圈的動畫，值班人員依然得自己猜這批貨該放哪裡、下一次由誰回報。這張圖畫得出等待背後的資訊限制，畫不出客戶改排收貨時要付出的代價。那個代價要向被耽擱的人問：他已經挪了哪些人手，哪一個時點後會另作安排，收到什麼訊息才能作決定。工程團隊負責說明系統狀態，業務同仁承接下一次通知，兩邊約好交接紀錄——誰都不用靠猜測替另一邊作保。今晚挑一張曾經停在待決的批次單，把畫面截圖交給值班同仁，請他照現行流程說出下一通電話要打給誰。
FLP 定理，常被問到的幾件事
設定超時就能避開 FLP 嗎？
超時可以觸發重試、改選或通知人工，是很有用的操作工具。在沒有已知延遲上界的模型裡，超時仍可能來自慢訊息。要主張最後一定決定，需另交代讓重試最終成功的條件，例如足夠長的穩定期——只加一個計時器，原先的資訊限制仍在。
圖中 C 稍後有回覆，為什麼還談永不終止？
圖只比較有限片段，讓人看見同一份接收紀錄可以對應不同的真實狀態。FLP 的完整證明進一步從雙價狀態出發，安排合法步驟，使系統持續保留可走向不同決定的可能性。每一封需送達的訊息最終都到達，整體決定仍能一直被往後推。雙時序是直覺入口——證明的工作比這幅圖更多。
FLP 和 CAP 定理在問同一件事嗎？
FLP 聚焦確定性共識在完全異步且容許停止故障下的終止保證。CAP 則把網路分割期間的資料一致性與可用性要求擺在一起分析。兩者都讓系統假設變得具體，題目與用語各有定義；評估服務時先寫出要保證的性質，再選合適的定理核對。
系統等待的理由講清楚，才能比較接下來要加哪一種假設。接著可讀 分割期間的一致性與可用性，辨認另一種保證邊界；再看 以選主與日誌處理實作上的共識，把穩定通訊的條件放回真實流程。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。