區塊基礎-容錯問題
分佈式容錯
區塊鏈，有一種理解爲分佈式統一賬本，那麼分佈式的架構肯定會存在一個容錯的問題。這裏簡單概述下容錯相關內容。
分佈式容錯約定概念：
-
節點：在一個網絡中，每一臺終端計算機稱爲一個節點，傳統架構中服務器\客戶端的模式，那麼服務器也看作一個節點。
-
消息：網絡中節點單獨工作，協作在一塊，需要一種機制，稱爲消息，也作爲消息傳遞。
-
消息丟失：網絡中不能保證所有消息都是能正常被傳遞和確認，這個原因是由於網絡中的帶寬、物理設備故障、惡意節點等原因，故無法保證所有的消息都是能正常傳遞和確認，那麼必然存在消息丟失。
-
消息確認：在消息傳遞的過程中，接收消息的節點接收到消息後返回一個確認信息給發送節點。
-
消息傳遞序號：在消息發送過程中，爲了防止重複發送的統一消息，在消息傳遞中加一個序列號。
-
狀態複製：在分佈式系統中，串形複製命令序列。
-
加鎖：串行狀態複製的時候，通過加鎖的方式保證單一執行修改。
-
票：弱化形式的鎖。檢查服務節點狀態，不對其進行加鎖。
上述大致說明了一些分佈式容錯的約定概念。接下來簡單介紹下一些協議。
理想化的兩階段協議
-
step-1 -
客戶端發起請求至所有分佈式的服務器 -
step-2 -
if -
發起請求的客戶端獲得了所有的服務器的鎖 -
then -
客戶端一次發送消息，結束後解鎖 -
else -
客戶端未獲得所有服務器的鎖 -
重新進入step-1 -
end
這是一個理想化的模式。類似數據庫系統，第一階段就是事務的準備階段，第二年階段就是提交或者回滾。
問題：
那麼通過兩階段，出現節點故障的狀態，那麼請求無法完全，理想化的兩階段協議必須要求節點都正常，如果只是一部分服務器處於鎖的狀態，將無法正常完成整個過程。且客戶端將無法判斷服務器節點鎖的狀態，導致系統出現故障，問題：如何有效解決這種這種模式？
PAXOS
在票上加一個序列號，服務節點在收到票的時候記錄票的序號，保證票不重複和本地記錄的一致。通過超過半數的票來作爲容錯機制。
票協議：
-
step-1 -
客戶端向所有節點發送帶序號的票 -
step-2 -
if -
客戶端收到半數服務節點收到票的回覆 -
then -
客戶端再次發起票，且加上命令消息一起發送給所有服務器 -
服務器節點收到消息，判斷票有效性後，存儲命令消息 -
服務器返回客戶端信息 -
else -
客戶端等待，返回step-1 -
endif -
step-3 -
if -
客戶端收到半數服務器的返回客戶端消息 -
客戶端通知所有服務器執行之前的命令 -
else -
客戶端等待，返回step-1 -
endif
這種票協議還是會出現服務節點存儲本地票號，但是客戶端在發起請求的時候票號會不一致，且命令存儲會出現不一致。故再對這種模式進行改進。
PAXOS大致流程：
引入本地記錄票號的計數、半數確認容錯。
| 服務端 | 客戶端 |
|---|---|
| 初始化 | 初始化 |
| 票號t=0、命令c | 票號Tmax=0、命令C、存儲命令的票Tc |
| step-1 | step-1 |
| 發起請求、t=t+1，請求票號爲t | |
| 服務節點判斷：t>Tmax、那麼Tmax=t，回覆確認（Tc、C） | |
| step-2 | step-2 |
| 客戶端如果收到半數服務節點回復確認、選擇（Tc、C）驗證Tc>0、那麼c=C、發送消息p(t、c ) | |
| 服務節點收到p、判斷t=Tmax、那麼C=c、Tc=t、回覆成功 | |
| step-3 | step-3 |
| 接收到半數以上服務節點回覆成功，向每個服務節點發送執行c操作 |
說明：
PAXOS中有三階段，三角色（提案者、接收者、學習者）
上述流程中一個p（t、c）稱爲一個提案，那麼提案根據算法存儲在半數以上的服務器，那麼後續再出現新的p（t、c）則因爲t的順序判斷，故會順序執行。可以通過反證法，同時出現兩個p（t、c）出現在服務節點，且都超過半數，那麼兩個p提案在服務器之間肯定會有一個不爲空的交集。根據兩個p中t的順序號，那麼肯定有一個p提案被存儲在服務器節點中，成爲有效提案。在step-2中t爲判斷爲與最高票編號比較，於是執行之前已經存儲的p提案中的c命令。
場景分析：
-
如果成功p提案的客戶端沒有故障，那麼直接告訴所有服務器執行命令c
-
如果客戶端在沒有告訴服務器執行命令的已經出現故障，那麼服務器等待下一個客戶端獲得提案再執行命令。後續客戶端發送請求的時候，服務器即可告訴客戶端之前有一個提案待執行，避免再次發送提案。
-
如果一般服務器出現故障，沒有達到半數，客戶端無法正常獲得回覆工作。
-
如果出現執行多命令情景，那麼引入實例、增加實例編號，c命令選中執行，客戶端通過新的實例編號來啓動新的實例。且服務器通過詢問附近服務器確認一致的決議。
-
算法中p2p網絡環境下，每一個節點可以是單一角色、也可以是多個角色。
Leslie Lamport在1989年提出PAXOS有興趣可以看看論文原文。