聰明屋視角
關注互聯網，關注技術開發，透析與分享移動互聯網行業最新動態分布式系統中的容錯形成區塊鏈
時間：2019-02-20 12:07:18 閱讀：78645次 分類：行業新聞
分布式系統是實現高可伸縮性，局部性和可用性的基本概念。但是，另一方面，從客戶端查看時，整個系統需要很多原創才能看起來一致。另外，據說構建具有完整功能的分布式系統幾乎是不可能的，并且有必要選擇應用程序應該強調哪些屬性。
除了描述這些分布式系統的特性外，我們還描述了具有高性能的區塊鏈的特征。最后，通過總結容錯屬性，我們將進一步探索區塊鏈的更大潛力，并希望通過討論每個高級區塊鏈項目（如Tendermint）來充分解釋MOLD應該瞄準的系統。
1.簡介（容錯概述和整體流程）
與單個系統不同，分布式系統存在部分故障。單個系統的整體故障通常會導致整個系統崩潰。另一方面，在部分故障中，系統可以在從部分故障恢復的同時繼續運行而不會嚴重影響整體性能。
在本文中，我們將按以下順序解釋容錯;即使系統的一部分發生故障，系統也可以繼續處理。
·什么樣的屬性是容錯的
·什么樣的失敗以及如何歸類
如何在分布式系統中實現容錯
·關于溝通失敗
·“可靠的多播”增加了過程的阻力
·關于分布式提交問題
2.什么是容錯？
容錯
容錯定義如下
即使發生故障也能忍受服務
此外，具有容錯性的系統有時被稱為高可靠性系統，并且與可靠性系統相關的要求分為以下四種。
失敗模型
分布式系統中進程的典型故障如下：
通信鏈路的故障也被分類。
例如，對于分布式故障，可能會發生虛假消息的傳遞，因此最難處理。
冗余可以隱藏故障。這很容易理解，例如考慮到哺乳動物有兩只眼睛，耳朵和肺部。即使這些分布式器官中的一些失效，您也可以在隱藏故障的同時使用該系統。這稱為物理冗余。冗余有三種類型：信息冗余，時間冗余和物理冗余。
3.流程靈活性
在描述容錯之后，我們考慮如何實現容錯。
流程復制
典型的方法是進程復制。在組中創建（復制）相同的進程稱為復制。通過在分布式系統中復制，即使在部分故障的情況下，也可以通過正常過程提供服務。我們將復制過程稱為副本。
有兩種方法可以重用（復制）。
·主要基礎協議（被動副本）
·重復寫協議（PositiveReplication）
在前者中，只有主副本處理來自客戶端的消息，而另一個副本備份主進程。盡管復制品之間的處理結果不一致并且更容易實現通信功能，但是主復制品的故障需要選擇算法，并且處理有些復雜。
在后一種情況下，所有副本都從客戶端接收和處理消息。此時，基于消息的處理需要總排序和原子性兩個屬性。因此，原子多播需要更復雜的通信功能。
kFault容忍度
在重復寫入協議中，據說存在k個容錯，即使它們失敗，k個分量也可以正常移動。如果您有分布式故障，則至少需要2k + 1個進程才能具有k容錯能力。
原子多播問題
作為上述復制模型的前提，存在所有請求必須以相同順序到達所有服務器的條件。這稱為原子多播問題。這將在第5章中詳細討論。
流程之間的協議
進程之間的協議問題對于為分布式系統提供容錯至關重要。分布式協議算法的目的是在有限數量的步驟中達成共識以實現彼此之間不會失敗的過程，并且在代表性過程中存在一般分布式問題。
分布式一般問題
在具有k個錯誤過程的系統中，僅當存在2k + 1個或更多個正常過程并且整體上存在N=＆lt; 3k + 1個過程時才達到協議。換句話說，只有超過三分之二的流程能夠正常運作才能達成協議。 （如果小于此值，則可能因過程失敗而受騙。）
附錄：容錯所需的正常節點數
對于許多協議，具有分布式阻塞的最大允許節點數稱為1/3。原因將在下面簡要描述。
設“N”為節點總數，“F”為分布式節點，“T”為正常共識所需的節點數。
例如，假設“N-F”的正常節點被分成相同的數字，并且數字如下。
（N-F）/2
由于“F”的分布式節點具有任意行為，為了正常達成共識，必須滿足以下表達式。
T> （N-F）/2 + F···1
另外，考慮到F的所有分布式節點都是離線的，其他正常節點可以采用一致性，因此以下表達式成立。
N-F≥T···2
從1·2，
N-F> （N-F）/2 + F
∴F＆lt; N3
基于上述，當總節點中的分布式節點的數量小于1/3時，通常可以達到一致。
4.可靠的客戶端 - 服務器通信
到目前為止，我們已經討論了分布式系統中進程的容錯能力并了解了復制。本章討論在通信鏈路上引入容錯。
P2P通信
分布式系統中的通信基礎是將一個進程連接到另一個進程的對等通信（一對一通信）。
TCP
TCP：用于可靠通信的點對點通信
TCP具有序列號，定時器，校驗和，確認，重傳控制，擁塞控制等機制。例如，可以通過包括TCP序列號和基于確認的重傳控制的確認來處理由于丟失消息而導致的遺漏失敗。
失敗時的RPC（遠程過程調用）
RPC的目的是以本地過程調用的形式實現進程間通信，而無需了解通信部分。在使用RPC的分布式系統中可能會發生五個障礙。
1.客戶端找不到服務器。
2.從客戶端到服務器的請求消息將丟失。
3.服務器收到請求后崩潰。
4.從服務器到客戶端的響應消息將丟失。
5.客戶端發送請求消息后發生故障。
作為針對每個的對策，存在設置異常處理和計時器（時間限制）的方法。
5.可靠的團隊溝通
我們在前一章重點介紹了一對一通信，因此我們在此解釋一對多組播通信的高可靠性。在分布式系統中，重要的是在不泄漏的情況下發送消息，包括向彼此的服務器發送訂單。
可靠的組播無故障
考慮按順序向每個成員發送消息。
發送方首先將多播消息保存在手頭的歷史存儲器中。此外，發送方從接收方接收傳輸確認通知（A高仿CK）。在A高仿CK中，最后一個消息標識符的輸入和返回已完成。如果由于消息丟失等原因而無法接收包含預期標識符的A高仿CK，則發送方重新發送該消息。
確保來自發件人的郵件以相同的順序傳遞到所有進程。
在分布式系統中，不是“過程”
具有“何時”發送方“在發送期間失敗，傳遞給所有剩余進程或被忽略”的屬性的可靠多播稱為虛擬同步。
此外，虛擬同步并以整體順序執行消息傳遞的通信稱為原子多播。
Isis實現虛擬同步的一個例子。 Isis保留并轉移mmessageM進行處理，直到它知道所有成員都收到了消息M.
6.分發提交
促進原子多播問題的問題稱為分布式提交。
原子提交
有必要在最后判斷是否始終提交或暫停不同類似網站的流程。這種類型的操作稱為原子提交。
6-1。兩階段提交協議（2PC）
兩階段提交協議（2PC）是實現原子提交的典型方法。顧名思義，每個階段包括兩個步驟，組織如下。
（第1階段[投票階段]）
組織者向所有參與者發送VOTE_REQUEST消息
2.收到VOTE_REQUEST消息的參與者如果能夠提交交易并通過發送VOTE_ABORT消息進行投票（如果需要中止），則會向組織者發送VOTE_COMMT消息。
（第2階段[提交階段]）
3.主辦方收集所有參與者的投票。如果所有投票都是COMMIT，我們承諾并向所有參與者發送GLOBAL_COMMIT消息。如果有多個ABORT，它決定中止事務并發送GLOBAL_ABORT消息。
4.參與者等待來自組織者的消息，如果它是GLOBAL_COMMIT本地則提交，如果是GLOBAL_ABORT則丟棄該事務。
在整個過程中，組織者和參與者執行以下狀態轉換。
阻止提交協議
上述兩階段提交協議存在很大問題。當組織者在第3階段失敗并且所有參與者都在等待來自組織者的消息時。參與者不能合作確定最終應采取的行動決定。因此，兩階段提交被稱為阻止提交協議。
事實上，在兩階段提交中很少發生阻塞，因此它沒有被大量使用，但是三階段提交協議被設計為避免阻塞的解決方案。
6-2。三階段提交
與兩階段提交協議不同，三階段提交協議滿足以下兩個條件。 [Skeen和Stonebraker，1983]指出這兩個條件對于非阻塞提交協議是必要和充分的。
1.沒有直接訪問COMMIT狀態或ABORT狀態。
2.無法做出最終決定或過渡到COMMIT狀態。
SKEEN，D.andSTONEBRAKER，M“AFormalModelofCrashRecoveryinaDistributedSystem。” IEEE Trans.Softw.Eng。，1983年3月
具體地，PRECOMMIT狀態在兩階段提交的兩個階段之間提供。
整個參與者和組織者改變了狀態如下。
兩階段提交之間的最大區別是所有進程都返回INIT，ABORT和PRECOMMIT狀態。由于它永遠不會處于READY狀態，因此剩余的進程總是做出最終決定，并且可以充當非阻塞協議。
三階段提交只是一個概念表示，即使組織者失敗，也沒有正常工作的機制。然而，在區塊鏈出現后，其歷史將發生很大變化。 Tendermint項目通過在區塊鏈中使用三階段提交來實現非阻塞協議。
7.區塊鏈中的容錯性
最后，基于上述內容，我們還將參考分布式區塊鏈系統中的容錯。
7-1。區塊鏈容錯
區塊鏈具有高度容錯能力。讓我們根據第2章中分類的四個可靠性要求，仔細研究區塊鏈的性質。
停止運行的區塊鏈系統的時間和數量很少。特別是在比特幣網絡中，可以說高可用性和可靠性非常低，因為即使某些節點發生故障，也可以實現零停機并繼續正常運行。
接下來，關于安全性，當系統在區塊鏈網絡中不能正常工作時，會出現“事務未處理和阻塞”，“網絡中的信息不共享信息和分叉分區”類問題。后者很可能會造成重大麻煩。
關于可維護性，可以說社區很容易劃分，比如像比特幣這樣的公共區塊鏈，很難從中恢復。比特幣網絡受到高度贊賞，因為它們具有高可用性和可靠性，因此無需恢復，但如果您希望可維護，則應考慮選擇私有鏈或聯合鏈。
此外，區塊鏈非常有意義，因為它為分布式故障提供了有效的解決方案，這被認為是最難處理的。具體而言，它是由PoW等代表的相干算法......通過形成激勵結構來處理分布的一般問題;礦工通過維持/貢獻而不是基于博弈論破壞網絡來獲得更多利潤。算法。應該指出的是，諸如硬叉之類的新問題正在發生，然而，可以說它已經取得了一些成功。另外，
Hyperledger采用的PBFT還通過設置領導節點來確認投票，從而實現高分布式容錯。
7-2 .Blcokchain流程的靈活性
考慮如何在容錯描述后實現容錯。
首先，有兩種方法可以處理復制。
1.主要的基礎協議
2.重復寫協議
使用1的主基礎協議的主協議是基于PoW一致性算法的區塊鏈。在PoW的情況下，它是主基中的本地寫協議的規范。成功找到PoW的nonce值作為獨占控件（領導者選擇算法）的礦工獲得了將塊添加為主服務器的權利。但是，當有權成為主服務器的節點同時出現時，區塊鏈將分叉。
另一方面，2的重復寫協議是基于PBFT的區塊鏈。各種基于PBFT的共識算法（包括Tendermint）沒有主服務器首先負責執行每個數據的更新，并且所有參與節點可以同時執行寫操作。也就是說，可以說PBFT類型一致性協議類似于重復寫入類型的主動拷貝協議。
7-3。區塊鏈高可靠性通信
我已經提到了區塊鏈過程，但這次我將重點關注通信鏈接。
在區塊鏈中，參與網絡的每個節點執行P2P通信并共享數據。另外，由領導者選擇算法選擇的主服務器執行多播，例如，當找到隨機數時，將新添加的塊的信息共享給每個參與節點。此時，考慮到在通信鏈路或節點中發生故障的情況，重要的是實現原子多播，其是虛擬同步并且以整體順序執行消息傳遞。
那么，區塊鏈中的原子多播問題和分布式提交問題是如何解決的？
在像比特幣這樣的PoW公共鏈中，原子組播尚未實現。因此，可能會發生頻繁的貨叉。由于每個節點隨時間正確共享數據，因此建立了一致性，但確認事務存儲在塊中需要10分鐘以上。
在這里，我們應該注意Tendermint一致性算法。通常，存在2PC（兩階段提交）作為實現原子提交的方法，并且已經提出了作為改進版本的3PC方法，但兩者都是不完整的。因此，Tendermint通過將區塊鏈與3PC方法混合并在循環方法下的節點上添加約束來實現原子提交。下一章將解釋這種創新的分布式提交問題的方法。
7-4。 Tendermint分布式提交（創新三階段提交模型）
首先，Tendermint是PBFT類型。在Hyperledger中，作為領導者的驗證者始終是相同的過程，但Tendermint具有領導者選擇算法，并通過循環方法確定性地確定領導者。領導者共同提出存儲在mempool中的下一個事務塊。通過此提議，Tendermint Consensus實施了3PC（三階段提交）并實施了原子多播。 Tendermint一致性算法可以大致分為三種狀態。
1.提議
基于基于基于領導的選擇算法基于樁數通過循環方法確定性地選擇的一組驗證者的提議。在這種狀態下開始投票。
2.預先投票
擬議區塊的第一次投票。一旦我們獲得三分之二或更多的批準，我們將繼續進行下一步，但要等到收集所有選票的時間限制。由于這個時間限制，可以說Tendermint是一種部分異步一致性算法。此外，投票算法具有1/3k的容錯能力。
3.預先承諾
超過2/3的投票前同意第二次投票。此時，如下所述，Tendermint的智能部分是未收集2/3或更多票數的衡量標準。
如前所述，通過為三階段提交設置PRECOMMIT階段，如果滿足以下條件，則可以實現阻塞協議。
1.沒有狀態直接轉換為COMMIT狀態或ABORT狀態
2.無法做出最終決定或過渡到COMMIT狀態。
在Tendermint中，在第二個投票階段投票的核查員預先提交被鎖定，并且只能在投票前投票超過鎖定塊數或塊數的2/3。通過鎖定過程，滿足上述兩個條件。換句話說，由于每個驗證器只能在預提交中對塊進行投票，因此它不實現fork機制。
換句話說，“Tendermint的共識是確保在網絡中的所有節點上完成添加塊的操作，或者根本不完成任何節點;實現最終結果的下一代共識協議。
蕪湖市聰明屋智能科技有限公司（原中江網絡），成立于2005年，經過10多年定制開發經驗，積累了大量技術儲備和定制開發經驗，率先創建安徽省內自主研發的云計算平臺，具有大數據、高并發等高強度計算能力，為眾多政府、學校、公安部門、中小企業解決數據計算與管理難題。2013年公司內部專門創建電商服務部，為企業提供全方位電商解決方案與配套服務。多次獲得國家、省市級領導接見，被國內近20家電視臺、報紙媒體爭相報道。至今，聰明屋智能科技服務過上市公司、大型國企、各類私企超800家，為多家公司提供各類政務系統、app開發定制、微信小程序開發定制、智能家居、電商系統、連鎖收銀等技術解決方案服務。同時，聰明屋智能科技在智能硬件方面、區塊鏈應用方面持續投入關注及創新。
售前咨詢熱線
工作日 9:00-18:00
關注聰明屋
友情鏈接：
