目錄
共識機制
編輯分布式計算和多代理系統中的一個基本問題是,在存在一些故障進程的情況下,實現系統的整體可靠性。這往往需要協調進程來達成共識,或者就計算過程中需要的一些數據值達成一致。共識的應用實例包括同意以何種順序向數據庫提交哪些事務、狀態機復制和原子廣播。現實世界中經常需要共識的應用包括云計算、時鐘同步、PageRank、意見形成、智能電網、狀態估計、無人機(以及一般的多個機器人/代理)的控制、負載平衡、xxx等。
問題描述
編輯共識問題要求一些進程(或代理)之間就單個數據值達成協議。一些進程(代理)可能會失敗或在其他方面不可靠,所以共識協議必須是容錯的或有彈性的。這些進程必須以某種方式提出他們的候選值,相互溝通,并就單一的共識值達成一致。
共識問題是多Agent系統控制中的一個基本問題。產生共識的一種方法是讓所有進程(代理)就一個多數值達成一致。在這種情況下,多數值要求至少有一個超過一半的可用票數(每個進程都有一票)。然而,一個或多個有問題的進程可能會歪曲結果,從而可能無法達成共識或不正確地達成共識。
解決共識問題的協議被設計用來處理數量有限的有缺陷的進程。這些協議必須滿足一些要求才能發揮作用。例如,一個微不足道的協議可以讓所有進程輸出二進制值1。這是不有用的,因此要求被修改為輸出必須在某種程度上取決于輸入。也就是說,一個共識協議的輸出值必須是某個進程的輸入值。另一個要求是,一個進程只能決定一次輸出值,而且這個決定是不可撤銷的。如果一個進程沒有經歷過失敗,那么它在執行過程中被稱為正確的。一個可以容忍停止失敗的共識協議必須滿足以下特性。
終止最終,每個正確的進程都會決定一些值。完整性如果所有正確的進程都提出了相同的值v {displaystyle v},那么任何正確的進程都必須決定v {displaystyle v}。協議每個正確的進程必須同意相同的值。
根據應用情況,完整性定義的變體可能是合適的。例如,一個較弱的完整性類型是決策值必須等于某個正確流程提出的值--不一定是所有的流程。在文獻中還有一個被稱為有效性的條件,它指的是一個進程發送的消息必須被傳遞的屬性。
一個能夠正確保證n個進程之間達成共識的協議,其中最多只有t個進程失敗,這個協議被稱為t-resilient。
在評估共識協議的性能時,有兩個感興趣的因素是運行時間和消息復雜性。運行時間用大O表示,即消息交換的輪數,是一些輸入參數(通常是進程的數量和/或輸入域的大小)的函數。消息復雜度是指協議產生的消息流量的數量。其他因素可能包括內存的使用和消息的大小。
計算的模型
編輯不同的計算模型可以定義一個共識問題。一些模型可以處理全連接圖,而另一些模型可以處理環和樹。在一些模型中,允許消息認證,而在其他模型中,進程是完全匿名的。共享內存模型,其中進程通過訪問共享內存中的對象進行通信,也是一個重要的研究領域。
具有直接或可轉移認證的通信通道
在大多數通信協議模型中,參與者通過認證的通道進行通信。這意味著消息不是匿名的,接收者知道他們收到的每條消息的來源。有些模型假設了一種更強的、可轉移的認證形式,即每條消息都由發送者簽名,這樣接收者不僅知道每條消息的直接來源,還知道最初創建該消息的參與者。這種更強的認證類型是由數字簽名實現的,當這種更強的認證形式可用時,協議可以容忍更多的故障。
這兩種不同的認證模式通常被稱為口頭交流和書面交流模式。在口頭交流模式中,信息的直接來源是已知的,而在更強的書面交流模式中,每一步接收者不僅了解信息的直接來源。
內容由匿名用戶提供,本內容不代表www.gelinmeiz.com立場,內容投訴舉報請聯系www.gelinmeiz.com客服。如若轉載,請注明出處:http://www.gelinmeiz.com/193142/