前幾天講了跟分散式系統有關的網路不可靠、時鐘不可靠的鬼故事，不可靠的東西這麼多，我們要如何判斷真與假呢？在分散式系統中，我們可以陳述我們對行為所做的假設（系統模型），然後設計符合這些假設的系統，只要演算法證明相關函數正確，意味者可靠的行為正在發生，儘管底層的其他系統模型提供的保證很少也是。

在 Day 12, 13 天，我們將會進一步了解分散式系統有關 真實 (truth) 的知識，這能幫助我們未來在設想假設時，我們的系統能提供保證到什麼程度。

多數決的真實 (The Truth Is Defined by the Majority)

只要多台節點認為你死亡，你就是死亡，儘管你是因為網路問題被丟棄你回覆的訊息，或者的 GC 跑的特別久都一樣，在分散式系統中你無法依靠單台節點來當法官，我們會用 quorum (法定人數) (2020 Day 24) 來在各節點中投票，所以一般來說多數決的節點數量一定是比一半多一點，也就能容忍一些節點死亡（3 台節點能容忍 1 台死亡，5 台節點則是 2 台），我們差不多在 Day 14 談 共識算法 (consensus algorithms) 看有關 quorum 的更多 細節。

領導者和鎖 (The leader and the lock)

有些主題用英文寫出來覺得正常，但也用中文翻譯出來看起來就很奇怪- -

很多分散式系統是使用 single-leader，想像一下 leader 你吃著火鍋唱著歌，忽然就被麻匪劫了（你被 quorum 節點們宣告死亡），而你又自認為你還是 leader 時，麻煩就出來了。

像下圖 8-4 的例子，展示了不正確實現分散式 lock 機制而造成資料損壞 bug，該 storage 只有在你取得資源 lease (租約) 的時候才寫入該資源，Client 1 取得 lease 後，不幸的被 GC 暫停所有行為了，當這個暫停久到 lease 到期了，此時 Client 2 就能針對該資源取得另一份 lease ，Client 1 GC 結束返回之後，誤以為它的 lease 還是有效而繼續進行寫入，所以該資源就被污染了。

擊劍令牌 (Fencing token)

除了使用鎖和 lease 保護資源外，我們會需要 fencing 技術來保護資源被上述例子的角色所污染，如下圖 8-5，現在 Lock service 除了回覆 lease 外，會多回覆 擊劍令牌 (Fencing token)，它就是個數字在每次取得 lease 時會累加，現在只要 Storage 多檢查後來寫入資源的 token 是不是比較小就可以了。

如果使用 Zookeeper 作為鎖服務，它的 zxid 或 node 版本 cversion 可以被當做 fencing token。

拜占庭錯誤 (Byzantine Faults)

真實的事談完了，我們來看看什麼是假的，在分散式系統中，如果你的節點有對你說謊的風險，舉例來說就是有節點宣稱他接收到訊息了但其實沒有，這種行為被稱為 拜占庭錯誤 (Byzantine Faults) ，在這種不信任的環境中取得共識的問題也被稱為 拜占庭將軍問題 (Byzantine Generals Problem)。

想了解拜占庭將軍問題，強烈建議看 李永樂老師的說明影片。

本系列文的分散式系統節點們雖然不可靠，但我們都是假設它們是誠實的，因為是你或你的組織架構起分散式系統，所以本質上它們是能被信任皫，倘若你的分散系統還要支援 拜占庭容錯 (Byzantine fault-tolerant) 的話，只會徒增你系統的複雜度而已，除非你的分散式系統是跑在點對點網路上，你得面對許多不同不由你控制的節點，就像比特幣那樣。

明天就結束這一章啦啦啦啦！