太上老君的煉丹爐之分佈式 Quorum NWR
- 2021 年 3 月 4 日
- 筆記
分佈式系列文章：
1.用三國殺講分佈式算法，舒適了吧？
2.用太極拳講分佈式理論，真舒服！
3.諸葛亮 VS 龐統，拿下 Paxos 共識算法
4.用動圖講解分佈式 Raft
5.韓信大招：一致性哈希
6.病毒入侵：全靠分佈式 Gossip 協議
7.這三年被分佈式坑慘了，曝光十大坑
8.太上老君的煉丹爐之分佈式 Quorum NWR
太白金星：聽聞老君最近在練神丹妙藥，可否與我一講？
太上老君：老白啊，我最近在練六顆丹藥：兩顆
延年丹、兩顆健步丹、兩顆恢復丹。太白金星：那這三個八卦爐定是練這三件法寶的了？
太上老君：正是正是。而且對於相同的丹藥，功效和大小還得完全一樣。
一、三個煉丹爐怎麼分配的
太白金星：老君，你的八卦爐怎麼分配的啊？
讓我們揭開老君的煉丹爐，看看六顆丹藥是怎麼分配的。
首先我們是很容易猜到丹爐是怎麼分配煉丹的：
- 一號丹爐煉兩顆
延年丹。 - 二號丹爐煉兩顆
健步丹。 - 三號丹爐煉兩顆
恢復丹。
那如此分配會有什麼問題呢？
我們試想一下，如果一號丹爐因為爐火太高炸裂了，那麼兩顆延年丹定會失敗。這和把雞蛋放到一個籃子裏面是一個道理。假如籃子不慎被打翻，裏面的雞蛋都掉出來，就都碎了。
太上老君：老白，我把鍋爐的蓋子揭開給你看看你就知道了。
- 一號丹爐煉一顆
延年丹和一顆健步丹。 - 二號丹爐煉一顆
延年丹和一顆恢復丹。 - 三號丹爐煉一顆
健步丹和一顆恢復丹。
太白金星：老君，為何要如此分配，每個丹藥的火候可不那麼好把控啊？
太上老君：老白，我可是煉丹大師，火候難不倒我。
太白金星：不愧是老君啊，這樣即使有一個丹爐有問題，至少能保證一顆能煉成，而不是兩顆都毀了。
映射到我們互聯網系統中：丹爐類似於服務器節點或數據庫節點，通過多個節點來相互備份數據來保證系統的高可用性（High Availability）。
二、如何保證丹藥品質一樣
2.1 一致性
太白金星：老君，你剛提到，兩顆延年丹需要保證功效一樣，大小一樣？
太上老君：確實如此，丹藥品質必須保持一致，我煉的都是九品丹藥，藥效差一點則是千差萬別。
太上老君說的品質保持一致到底怎麼回事？
一號丹爐裏面的延年丹和二號丹爐的延年丹如何保證品質一致呢？
這不就是我們常常說的分佈式一致性嗎？兩顆丹藥分佈在不同的丹爐中，需要保證品質一致。
如下圖所示，這兩顆延年丹的一大一小，顏色也有不同，這就是品質不一樣。
而在架構設計中，比如請求訪問到不同的數據庫，查到的數據都是一樣的，這就是一致性。
如下圖所示：瀏覽器訪問數據庫 1 和數據庫 2 中的數據 A，結果返回的都是 A = 1。
2.2 最終一致性和強一致性
分佈式中的一致性又分為最終一致性和強一致性。
所謂強一致性就是寫操作完成後，任何後續訪問都能讀到更新後的值。這就是CP系統所要求的一致性和分區容錯性。。
那放到煉丹中怎麼理解？
比如老君給一號丹爐的延年丹加入了蓮花這種藥材，給二號丹爐的延年丹也這麼操作，那麼老白揭開爐蓋看到的兩顆延年丹的成分是一樣的。
而最終一致性就是不保證後續訪問都能讀到更新後的值，但是經過一段時間後，再去讀，就能得到相同的值。也就是說，在這段時間內，可能讀到舊的數據。這就是 AP系統所要求的可用性和分區容錯性。
放到煉丹中怎麼理解？
比如老君給一號丹爐的延年丹加入了蓮花，而經過了一個時辰後，才給二號丹爐加雪蓮，那麼在這個時辰內，看到的兩顆延年丹的成分就不一樣了。但經過一個時辰後，最終成分一樣。
三、可控的品質：Quorum NWR 協議
Quorum NWR
假如延年丹必須保證品質的強一致性，而健步丹只需要保證品質的最終一致性，這個該怎麼控制呢？
這個可沒有難倒老君，因為老君懂得分佈式協議：Quorum NWR。
Quorum 這個單詞的意思：(會議的)法定人數。主要是看後面三個大寫字母：N、W、R。由 NWR 來控制一致性。
3.1 參數 N
我們還是來看下丹爐中的情況，兩顆延年丹是互為備份的，相當於有兩個副本。
N 稱作副本數，又叫做複製因子（Replication Factor）。表示同一份數據有多少個副本，所以：延年丹的 N = 2。依次類推：健步丹的 N = 2，恢復丹的 N = 2。如下圖所示：
那 N 可以變嗎？
如下圖所示：比如我想煉 3 顆延年丹，也就是每個丹爐都有延年丹，那就把 N 改成 3 就可以了。而健步丹只需要煉一顆足以，那一號丹爐煉就可以了，所以N = 1。
3.2 參數 W
指定了副本數 N 之後，就可以對副本數據進行讀寫操作。
- 讀操作：查看所在丹爐內丹藥的情況。
- 寫操作：給丹藥添加藥材、提高溫度。
那多個丹藥該如何執行讀寫操作呢？對於寫操作，我們有 W 參數，對於讀操作，我們有 R 參數。
W 稱為寫一致性級別（Write Consistency Level），表示成功完成 W 個副本更新，才完成寫操作。
比如設置延年丹的 W = 2，表示對延年丹執行寫操作時，完成了 2 個副本的更新時，才完成寫操作。
如下圖所示：一號丹爐和二號丹爐中的延年丹都加入了蓮花，而三號丹爐中的延年丹未加入蓮花。也就是只完成了兩個副本的更新，符合 W = 2 這個條件，即寫操作完成。
但是大家發現問題沒，三號丹爐的延年丹未加入蓮花，那怎麼保證太上老君查看丹藥情況時，得知是已加入蓮花呢？也就是如何保證讀寫的強一致性，這就要用到第三個參數了：R。
3.3 參數 R
R 稱為讀一致性級別（Read Consistency Level），表示讀取一個數據對象時，需要讀 R 個副本，然後返回 R 個副本中最新的那份數據。
回到煉丹的問題中，設置延年丹的 R = 2，也就是查看延年丹的情況時，只需要查看兩個丹爐內的延年丹的情況，然後返回最新的延年丹的情況就可以了。
-
假設查看的是一號和二號丹爐內的延年丹，返回的情況都是：已加入蓮花。這種場景是一致性的。
-
假設查看的是一號和三號丹爐內的延年丹，一號丹爐的延年丹是已加入蓮花，三號丹爐是未加入蓮花，但是三號丹爐內的延年丹最後一次操作時間是早於一號丹爐的，所以返回一號丹爐內延年丹的情況：已加入蓮花。這種場景也是一致性的。
通過上面的兩種場景，我們知道，通過設置 R = 2，即使讀到第三份未更新的數據，也能返回更新後的數據，實現強一致性。
3.4 參數組合
參數 N、W、R 的不同組合將會帶來不同的一致性效果。
-
比如上面的例子，N = 3，W = 2，R = 2，W + R > N，對於客戶端來講，整個系統能保證強一致性，一定能返回更新後的那份數據。
-
當 W + R <= N 時，對於客戶端來講，整個系統只能保證最終一致性，訪問數據期間可能會返回舊數據。
參數不同，效果不同，分佈式系統需要場景來配置。
四、應用
InfluxDB 企業版是時序數據庫，它有四種寫一致性級別：
- any：W + R < N，W = 1，任何一個節點寫入成功後，或者寫入 Hinted-handoff 緩存（等下次重傳），返回成功給客戶端。
- one：W + R < N，W = 1，任何一個節點寫入成功後，立即返回成功給客戶端，不包括寫入 Hinted-handoff 緩存
- quorum：W + R > N，大多數節點寫入成功後，就返回成功給客戶端。（要求 N 大於2）
- all：W = N，所有節點都寫入成功後，返回成功。
另外對於 時序數據庫 InfluxDB 來說，讀操作需要讀取大量數據，為了保證讀取的高效，它不支持讀一致性級別（R = N），但是可以通過設置寫一致性級別為 all，來實現強一致性。
InfluxDb 實現了 Quorum NWR，當線上業務需要臨時做些一致性調整時，設置不同的寫一致性級別即可完成快速切換。
五、總結
本文通過太上老君和太白金星關於煉丹的對話，引申出自定義一致性的分佈式協議：Quorum NWR 協議。
- 丹爐比喻節點，丹藥比作數據，多個丹藥稱作副本。
- N 代表副本數，W 代表寫多少個副本數，R 代表讀多少個副本數。
- 當 N 大於節點數時，就會出現一個節點存在多個副本的情況，這個節點故障時，多個副本會受到影響。
- W + R > N 時，代表強一致性。
- W = N 時，讀性能好。R = N，寫性能好。
- W = R = (N+1)/2，容錯能力好，能容忍 少數節點（也就是(N-1)/2） 個節點故障。
- 如何設置 N、W、R 值，取決於我們的系統該往哪方面優化。
- Quorum NWR 分佈式算法給業務提供了按需選擇一致性級別的靈活度，彌補了 AP 型系統缺乏強一致性的缺點。
太白金星：預祝你煉丹成功！我要去分享和留言了！
作者簡介：悟空，8年一線互聯網開發和架構經驗，用故事講解分佈式、架構設計。《JVM性能優化實戰》專欄作者，開源了《Spring Cloud 實戰 PassJava》項目，自主開發了一個 PMP 刷題小程序。關注可免費刷題。
我是悟空，努力變強，變身超級賽亞人！
