本發(fā)明涉及分布式計算技術，尤其涉及一種分布式系統(tǒng)及消息處理方法。

背景技術：

分布式系統(tǒng)是目前普遍使用的計算系統(tǒng)，應用于區(qū)塊鏈、ZooKeeper分布式服務框架等等諸多領域。

分布式系統(tǒng)的工作過程中，需要對來自客戶端的待處理的消息形成共識(Consensus)，即分布式系統(tǒng)的全部節(jié)點或多數節(jié)點對接收的消息進行確認，然后對消息進行同步存儲/處理。

例如，當分布式系統(tǒng)應用在私有區(qū)塊鏈或聯(lián)盟區(qū)塊鏈中時，各節(jié)點對于客戶端提交的交易記錄的根據共識算法形成共識(即確認交易記錄的可靠性)，會在各個節(jié)點的維護的區(qū)塊鏈中存儲，保證了各個節(jié)點存儲的交易記錄的一致性。

分布式系統(tǒng)目前采用的共識算法往往側重于達成共識的效率，或在達成共識的過程中保證一定的容錯性能，容錯性能是指存在故障節(jié)點或惡意節(jié)點時，保證多數的節(jié)點仍然能夠達成共識。

對于相關技術提供的用于保證達成共識的效率的共識算法來說，由于無法檢測故障節(jié)點和惡意節(jié)點，因此難以保證共識的可靠性。

技術實現要素：

本發(fā)明實施例提供一種分布式系統(tǒng)及消息處理方法，能夠保證節(jié)點針對消息高效達成共識的同時，還能夠檢測異常節(jié)點。

本發(fā)明實施例的技術方案是這樣實現的：

第一方面，本發(fā)明實施例提供一種分布式系統(tǒng)，包括：

客戶端和多個節(jié)點；

所述節(jié)點，用于在第一共識模式中新的共識周期到達時，通過執(zhí)行選舉操作確定處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)；其中，

所述節(jié)點，還用于處于主節(jié)點的狀態(tài)時，驗證所述客戶端發(fā)送的消息的數字簽名，將所述消息發(fā)送到所述從節(jié)點；接收到超出預定數量的所述從節(jié)點的確認接收通知并驗證所述確認接收通知的數字簽名，持久化存儲所述消息，向所述從節(jié)點發(fā)送存儲消息通知；

所述節(jié)點，還用于處于從節(jié)點的狀態(tài)時，接收到所述主節(jié)點發(fā)送的所述消息時向所述客戶端返回結果；驗證所接收的消息的數字簽名，向所述主節(jié)點發(fā)送確認接收通知；驗證所接收的存儲消息通知的數字簽名，持久化存儲所接收的消息；

所述客戶端，用于根據所述從節(jié)點接收到所述消息時返回的結果，確定異常節(jié)點。

第二方面，本發(fā)明實施例提供一種消息處理方法，包括：

在第一共識模式中新的共識周期到達時，分布式系統(tǒng)中的節(jié)點通過執(zhí)行選舉操作處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)；其中，

所述節(jié)點處于主節(jié)點的狀態(tài)時接收所述客戶端的消息，驗證所述消息的數字簽名，將所述消息發(fā)送到所述從節(jié)點；

所述節(jié)點處于從節(jié)點的狀態(tài)時，接收到所述主節(jié)點發(fā)送的所述消息并向所述客戶端返回結果，驗證所接收的消息的數字簽名后向所述主節(jié)點發(fā)送確認接收通知；

所述節(jié)點處于主節(jié)點的狀態(tài)時，接收到超出預定數量的所述從節(jié)點的確認接收通知，驗證所述確認接收消息的數字簽名后持久化存儲所述消息，向所述從節(jié)點發(fā)送存儲消息通知；

所述節(jié)點處于從節(jié)點的狀態(tài)時，驗證所接收的存儲消息通知的數字簽名后持久化存儲所接收的消息；

所述客戶端根據所述從節(jié)點接收到所述消息時返回的結果，確定異常節(jié)點。

第三方面，本發(fā)明實施例提供一種消息處理方法，應用于分布式系統(tǒng)中的節(jié)點，包括：

在第一共識模式中新的共識周期到達時，分布式系統(tǒng)中的節(jié)點通過執(zhí)行選舉操作處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)；其中，

所述節(jié)點處于主節(jié)點的狀態(tài)時接收所述客戶端的消息，驗證所述消息的數字簽名，將所述消息發(fā)送到所述從節(jié)點；

所述節(jié)點處于從節(jié)點的狀態(tài)時，接收到所述主節(jié)點發(fā)送的所述消息并向所述客戶端返回結果，驗證所接收的消息的數字簽名后向所述主節(jié)點發(fā)送確認接收通知；

所述節(jié)點處于主節(jié)點的狀態(tài)時，接收到超出預定數量的所述從節(jié)點的確認接收通知，驗證所述確認接收消息的數字簽名后持久化存儲所述消息，向所述從節(jié)點發(fā)送存儲消息通知；

所述節(jié)點處于從節(jié)點的狀態(tài)時，驗證所接收的存儲消息通知的數字簽名后持久化存儲所接收的消息；

所述消息，用于供客戶端確定異常節(jié)點。

上述方案中，所述從節(jié)點向所述客戶端返回結果攜帶所述消息的唯一性字段和所述從節(jié)點的數字簽名，用于供所述客戶端驗證所接收結果的數字簽名后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，確定不一致的唯一性字段對應的從節(jié)點為出錯節(jié)點，以及確定未返回相應結果的從節(jié)點為故障節(jié)點。

上述方案中，所述從節(jié)點所返回的結果還攜帶所述從節(jié)點所接收消息的序列號，用于供所述客戶端根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出不一致數量閾值時，判定所述主節(jié)點為惡意節(jié)點。

上述方案中，還包括：

所述節(jié)點在所述客戶端確定所述主節(jié)點為惡意節(jié)點，或者，確定所述從節(jié)點中存在故障節(jié)點時，切換到第二共識模式。

上述方案中，還包括：

所述節(jié)點在切換到所述第二共識模式的準備階段，將所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向所述客戶端發(fā)送攜帶相應節(jié)點的數字簽名的一致性確認；

所述一致性確認，用于供所述客戶端在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點繼續(xù)切換到所述第一共識模式；未在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點繼續(xù)切換到所述第二共識模式。

上述方案中，還包括：

所述節(jié)點在切換到所述第二共識模式的準備階段，將所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向消息的發(fā)送節(jié)點發(fā)送攜帶相應節(jié)點的數字簽名的數據確認；

所述數據確認，用于供所述客戶端在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認時，或在預定時間內任一節(jié)點未接收到其他節(jié)點發(fā)送的數據確認時，觸發(fā)所述分布式系統(tǒng)的節(jié)點繼續(xù)切換到所述第二共識模式。

上述方案中，還包括：

所述主節(jié)點在所述第二共識模式中統(tǒng)計到與所述從節(jié)點針對所接收的消息形成共識的次數超過主節(jié)點共識次數閾值時，與所述從節(jié)點切換到所述第一共識模式。

上述方案中，所述主節(jié)點在所述第二共識模式中統(tǒng)計到與所述從節(jié)點針對所接收的消息形成共識的次數超過主節(jié)點共識次數閾值時，與所述從節(jié)點切換到所述第一共識模式，包括：

所述主節(jié)點在所述第二共識模式中統(tǒng)計到針對所接收的消息形成共識的次數超過所述主節(jié)點共識次數閾值時，向所述從節(jié)點發(fā)送切換到所述第一共識模式的通知，并在接收到全部所述從節(jié)點發(fā)送的切換確認時，與所述從節(jié)點保持節(jié)點的狀態(tài)切換到所述第一共識模式。

上述方案中，還包括：

所述從節(jié)點在接收到切換到所述第一共識模式的通知時，統(tǒng)計到針對所接收的消息形成共識的次數超過從節(jié)點共識次數閾值時，向所述主節(jié)點發(fā)送切換確認。

上述方案中，所述從節(jié)點未接收到所述主節(jié)點的心跳信息時，或者，所述主節(jié)點為惡意節(jié)點時，通過執(zhí)行選舉操作確定處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)。

上述方案中，所述節(jié)點在新的共識周期到達、且未接收到其他節(jié)點發(fā)送的心跳信息時，向所述其他節(jié)點發(fā)送選舉請求，所述選舉請求攜帶所述節(jié)點的數字簽名，當接收預定數量的其他節(jié)點返回的選舉確認時，轉換為主節(jié)點的狀態(tài)，定期向所述其他節(jié)點發(fā)送心跳信息；其中，所述選舉確認為所述其他節(jié)點驗證所述選取請求攜帶的數字簽名后發(fā)送；

所述節(jié)點在新的共識周期到達、且接收到其他節(jié)點發(fā)送的心跳信息時轉換為從節(jié)點的狀態(tài)。

第四方面，本發(fā)明實施例提供一種分布式系統(tǒng)中的節(jié)點，包括：

選舉單元，用于在第一共識模式中新的共識周期到達時，通過執(zhí)行選舉操作確定處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)；其中，

主節(jié)點單元，用于當所述節(jié)點處于主節(jié)點的狀態(tài)時接收所述客戶端的消息，驗證所述消息的數字簽名，將所述消息發(fā)送到所述從節(jié)點；

從節(jié)點單元，用于當所述節(jié)點處于從節(jié)點的狀態(tài)時，接收到所述主節(jié)點發(fā)送的所述消息并向所述客戶端返回結果，驗證所接收的消息的數字簽名后向所述主節(jié)點發(fā)送確認接收通知；

所述主節(jié)點單元，用于當所述節(jié)點處于主節(jié)點的狀態(tài)時，接收到超出預定數量的所述從節(jié)點的確認接收通知，驗證所述確認接收消息的數字簽名后持久化存儲所述消息，向所述從節(jié)點發(fā)送存儲消息通知；

所述從節(jié)點單元，用于當所述節(jié)點處于從節(jié)點的狀態(tài)時，驗證所接收的存儲消息通知的數字簽名后持久化存儲所接收的消息；所述消息用于供客戶端確定異常節(jié)點。

上述方案中，所述從節(jié)點向所述客戶端返回結果攜帶所述消息的唯一性字段和所述從節(jié)點的數字簽名，用于供所述客戶端驗證所接收結果的數字簽名后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，確定不一致的唯一性字段對應的從節(jié)點為出錯節(jié)點，以及確定未返回相應結果的從節(jié)點為故障節(jié)點。

上述方案中，所述從節(jié)點所返回的結果還攜帶所述從節(jié)點所接收消息的序列號，用于供所述客戶端根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出不一致數量閾值時，判定所述主節(jié)點為惡意節(jié)點。

上述方案中，還包括：

切換單元，用于在所述客戶端確定所述主節(jié)點為惡意節(jié)點，或者，確定所述從節(jié)點中存在故障節(jié)點時，切換到第二共識模式。

上述方案中，所述切換單元，還用于在切換到所述第二共識模式的準備階段，將所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向所述客戶端發(fā)送攜帶相應節(jié)點的數字簽名的一致性確認；

所述一致性確認，用于供所述客戶端在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點繼續(xù)切換到所述第一共識模式；未在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點繼續(xù)切換到所述第二共識模式。

上述方案中，所述切換單元，還用于在切換到所述第二共識模式的準備階段，將所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向消息的發(fā)送節(jié)點發(fā)送攜帶相應節(jié)點的數字簽名的數據確認；

所述數據確認，用于供所述客戶端在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認時，或在預定時間內任一節(jié)點未接收到其他節(jié)點發(fā)送的數據確認時，觸發(fā)所述分布式系統(tǒng)的節(jié)點繼續(xù)切換到所述第二共識模式。

上述方案中，所述主節(jié)點單元，還用于當所述節(jié)點處于主節(jié)點的狀態(tài)，并在所述第二共識模式中統(tǒng)計到與所述從節(jié)點針對所接收的消息形成共識的次數超過主節(jié)點共識次數閾值時，與所述從節(jié)點切換到所述第一共識模式。

上述方案中，所述主節(jié)點單元，還用于在所述第二共識模式中統(tǒng)計到針對所接收的消息形成共識的次數超過所述主節(jié)點共識次數閾值時，向所述從節(jié)點發(fā)送切換到所述第一共識模式的通知，并在接收到全部所述從節(jié)點發(fā)送的切換確認時，與所述從節(jié)點保持節(jié)點的狀態(tài)切換到所述第一共識模式。

上述方案中，所述從節(jié)點單元，還用于當所述節(jié)點處于從節(jié)點的狀態(tài)時，在接收到切換到所述第一共識模式的通知時，統(tǒng)計到針對所接收的消息形成共識的次數超過從節(jié)點共識次數閾值時，向所述主節(jié)點發(fā)送切換確認。

上述方案中，所述選舉單元，還用于當未接收到所述主節(jié)點的心跳信息時，或者，所述主節(jié)點為惡意節(jié)點時，通過重新執(zhí)行選舉操作確定處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)。

上述方案中，所述選舉單元，還用于當在新的共識周期到達、且未接收到其他節(jié)點發(fā)送的心跳信息時，向所述其他節(jié)點發(fā)送選舉請求，所述選舉請求攜帶所述節(jié)點的數字簽名，當接收預定數量的其他節(jié)點返回的選舉確認時，轉換為主節(jié)點的狀態(tài)，定期向所述其他節(jié)點發(fā)送心跳信息；其中，所述選舉確認為所述其他節(jié)點驗證所述選取請求攜帶的數字簽名后發(fā)送；

所述選舉單元，還用于當在新的共識周期到達、且接收到其他節(jié)點發(fā)送的心跳信息時轉換為從節(jié)點的狀態(tài)。

第五方面，本發(fā)明實施例提供一種消息處理方法，包括：

向分布式系統(tǒng)的節(jié)點中的主節(jié)點發(fā)送消息，所述消息攜帶所述客戶端的數字簽名；

其中，所述數字簽名用于供所述主節(jié)點進行驗證，并將所接收的消息攜帶所述主節(jié)點的數字簽名，發(fā)送給所述分布式系統(tǒng)中的從節(jié)點；

接收所述從節(jié)點在接收到所述消息時返回的結果；

根據所述從節(jié)點接收到所述消息時返回的結果，確定異常節(jié)點。

第六方面，本發(fā)明實施例提供一種客戶端，包括：

通信單元，用于向分布式系統(tǒng)的節(jié)點中的主節(jié)點發(fā)送消息，所述消息攜帶所述客戶端的數字簽名；

其中，所述數字簽名用于供所述主節(jié)點進行驗證，并將所接收的消息攜帶所述主節(jié)點的數字簽名，發(fā)送給所述分布式系統(tǒng)中的從節(jié)點；

所述通信單元，用于接收所述從節(jié)點在接收到所述消息時返回的結果；

檢測單元，用于根據所述從節(jié)點接收到所述消息時返回的結果，確定異常節(jié)點。

上述方案中，所述檢測單元，還用于驗證所接收結果的數字簽名后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，確定不一致的唯一性字段對應的從節(jié)點為出錯節(jié)點，以及確定未返回相應結果的從節(jié)點為故障節(jié)點。

上述方案中，所述檢測單元，還用于根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出不一致數量閾值時，判定所述主節(jié)點為惡意節(jié)點。

上述方案中，還包括：

切換單元，用于確定所述主節(jié)點為惡意節(jié)點，或者，確定所述從節(jié)點中存在故障節(jié)點時，觸發(fā)所述分布式系統(tǒng)的節(jié)點切換到第二共識模式。

上述方案中，所述切換單元，還用于在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點返回所述第一共識模式；未在預定時間內接收到全部所述節(jié)點的一致性確認時，通知全部所述節(jié)點繼續(xù)切換到所述第二共識模式；

其中，所述一致性確認，為各所述節(jié)點在切換到所述第二共識模式的準備階段，將各所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，并在確認一致時發(fā)送，且攜帶相應節(jié)點的數字簽名。

上述方案中，所述切換單元，還用于在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認時，或在預定時間內任一所述節(jié)點未接收到其他節(jié)點發(fā)送的數據確認時，觸發(fā)所述分布式系統(tǒng)的節(jié)點繼續(xù)切換到所述第二共識模式；

其中，所述數據確認，為各所述節(jié)點在切換到所述第二共識模式的準備階段，將各所述節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較并在確認一致時發(fā)送，且攜帶相應節(jié)點的數字簽名。

第七方面，本發(fā)明實施例提供一種存儲介質，存儲有可執(zhí)行指令，用于執(zhí)行本發(fā)明實施例提供的消息處理方法。

本發(fā)明實施例具有這樣的有益效果：

1)采用數字簽名的方式保證通信的可靠性：對于任意通信的雙方均采用數字簽名的方式，即發(fā)送方在發(fā)送消息時會攜帶消息的數字簽名例如，使用發(fā)送方的不對稱加密算法的私鑰對消息的摘要進行加密，形成發(fā)送方的數字簽名，接收方通過驗證數字簽名確保消息的可靠性，即讀消息的簽名使用不對稱加密算法的公鑰(保證接收方和發(fā)送方使用相同的不對稱加密算法，則接收方預先獲知公鑰)進行解密，對解密得到的摘要與從消息中提取的摘要比對，如果一致說明數字簽名驗證通過，發(fā)送方發(fā)送的消息是可靠的。

2)從節(jié)點在接收主節(jié)點發(fā)送的消息時，會直接向客戶端返回結果，在結果中攜帶必要的信息如唯一性字段、消息序列號和數字簽名等，這樣，客戶端可以直接根據從節(jié)點返回的結果來判定從節(jié)點達成共識的情況，能夠容易地檢測出異常節(jié)點。

附圖說明

圖1是本發(fā)明實施例提供的分布式系統(tǒng)100應用于區(qū)塊鏈系統(tǒng)的一個可選的結構示意圖；

圖2是本發(fā)明實施例提供的區(qū)塊結構一個可選的示意圖；

圖3-1是本發(fā)明實施例提供的節(jié)點200的一個可選的軟硬件結構示意圖；

圖3-2是本發(fā)明實施例提供的客戶端300的一個可選的軟硬件結構示意圖；

圖4是本發(fā)明實施例提供的在第一共識模式中各節(jié)點執(zhí)行選舉操作而確定主節(jié)點和從節(jié)點的一個可選的示意圖；

圖5是本發(fā)明實施例提供的分布式系統(tǒng)的節(jié)點在第一共識模式中達成共識、并檢測故障節(jié)點和惡意節(jié)點的一個可選的流程示意圖；

圖6是本發(fā)明實施例提供分布式系統(tǒng)在第一共識模式和第二模式中進行切換的一個可選的流程示意圖；

圖7是本發(fā)明實施例提供分布式系統(tǒng)在第一共識模式和第二模式中進行切換的一個可選的流程示意圖；

圖8是發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)采用RAFT算法達成共識的一個可選的流程示意圖；

圖9是發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)采用PBFT算法達成共識的一個可選的流程示意圖；

圖10是本發(fā)明實施例提供的實現自適應共識算法運行狀態(tài)圖；

圖11是本發(fā)明實施例提供的T-RAFT算法共識的實現示意圖；

圖12是本發(fā)明實施例提供的在PBFT算法切換的準備階段進行切換回T-RAFT算法的一個可選的流程示意圖；

圖13是本發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)從T-RAFT算法共識切換到PBFT算法共識的一個可選的流程示意圖；

圖14是本發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)PBFT算法共識模式切換到T-RAFT算法共識模式的一個可選的流程示意圖；

圖15是本發(fā)明實施例提供的分布式系統(tǒng)應用于聯(lián)盟鏈系統(tǒng)的一個可選的場景示意圖。

具體實施方式

以下結合附圖及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所提供的實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。另外，以下所提供的實施例是用于實施本發(fā)明的部分實施例，而非提供實施本發(fā)明的全部實施例，在不沖突的情況下，本發(fā)明實施例記載的技術方案可以任意組合的方式實施。

1)分布式系統(tǒng)，由多個節(jié)點通過網絡通信而連接形成的系統(tǒng)；還包括客戶端，消息的具體內容根據實際的業(yè)務場景而有區(qū)別，例如，消息可以為交易記錄、供節(jié)點的狀態(tài)機執(zhí)行的指令等。

2)共識，在分布式系統(tǒng)中，節(jié)點對其他節(jié)點發(fā)送的消息的正確性進行驗證，如驗證成功則向發(fā)送消息的節(jié)點發(fā)送確認，并將該消息進行持久化存儲，以用于支持后續(xù)進行查詢。

例如，在區(qū)塊鏈系統(tǒng)中，節(jié)點對其他節(jié)點提交的新區(qū)塊的有效性進行驗證，如驗證成功則向發(fā)送新區(qū)塊的節(jié)點發(fā)送確認，并將該新區(qū)塊添加到相應節(jié)點所存儲的區(qū)塊鏈的尾部。

3)共識模式，也稱為共識算法，用于保證分布式系統(tǒng)的節(jié)點達成共識的算法，例如，包括：

能夠實現較高的共識效率、并且能夠檢測到節(jié)點故障或者拜占庭問題(一方向另一方發(fā)送消息，另一方沒有收到，或者收到了錯誤的信息的情況)、但是無法解決拜占庭問題的共識模式，本文中也稱為第一共識模式，例如，包括Paxos算法；遞歸容錯算法(RAFT，Recursive Algorithm for Fault Tolerance)；

用于解決拜占庭問題的共識模式，本文中也稱為第二共識模式，例如，包括：

拜占庭容錯(BFT，Byzantine Fault Tolerance)算法、實用拜占庭容錯(PBFT，Practical Byzantine Fault Tolerance)算法、遞歸容錯算法-拜占庭容錯(BFT-RAFT，Byzantine Fault Tolerance Recursive Algorithm for Fault Tolerance)、拜占庭容錯(BFT-Paxos)算法等。

4)共識模式切換，也稱為共識模式自適應，分布式網絡的節(jié)點共識算法在網絡環(huán)境良好的時候自動采用共識效率高可以檢測到異常節(jié)點(如拜占庭問題的節(jié)點)的共識算法，當發(fā)現惡意節(jié)點或者節(jié)點錯誤的時候，可以自動切換到以支持解決拜占庭容錯的共識算法。

本發(fā)明實施例涉及的分布式系統(tǒng)是由客戶端、多個節(jié)點(接入網絡中的任意形式的計算設備，如服務器、用戶終端)通過網絡通信的形式連接形成。

以分布式系統(tǒng)為區(qū)塊鏈系統(tǒng)為例，參見圖1，圖1是本發(fā)明實施例提供的分布式系統(tǒng)100應用于區(qū)塊鏈系統(tǒng)的一個可選的結構示意圖，由多個節(jié)點(接入網絡中的任意形式的計算設備，如服務器、用戶終端)和客戶端形成，節(jié)點之間形成組成的點對點(P2P，Peer To Peer)網絡，P2P協(xié)議是一個運行在傳輸控制協(xié)議(TCP，Transmission Control Protocol)協(xié)議之上的應用層協(xié)議。

參見圖1示出的區(qū)塊鏈系統(tǒng)中各節(jié)點的功能，涉及的功能包括：

1)路由，節(jié)點具有的基本功能，用于支持節(jié)點之間的通信。

節(jié)點除具有路由功能外，還可以具有以下功能：

2)應用，用于部署在區(qū)塊鏈中，根據實際業(yè)務需求而實現特定業(yè)務，記錄實現功能相關的數據形成記錄數據，在記錄數據中攜帶數字簽名以表示任務數據的來源，將記錄數據發(fā)送到區(qū)塊鏈系統(tǒng)中的其他節(jié)點，供其他節(jié)點在驗證記錄數據來源以及完整性成功時，將記錄數據添加到臨時區(qū)塊中。

例如，應用實現的業(yè)務包括：

2.1)錢包，用于提供進行電子貨幣的交易的功能，包括發(fā)起交易(即，將當前交易的交易記錄發(fā)送給區(qū)塊鏈系統(tǒng)中的其他節(jié)點，其他節(jié)點驗證成功后，作為承認交易有效的響應，將交易的記錄數據存入區(qū)塊鏈的臨時區(qū)塊中；當然，錢包還支持查詢電子貨幣地址中剩余的電子貨幣；

2.2)共享賬本，用于提供賬目數據的存儲、查詢和修改等操作的功能，將對賬目數據的操作的記錄數據發(fā)送到區(qū)塊鏈系統(tǒng)中的其他節(jié)點，其他節(jié)點驗證有效后，作為承認賬目數據有效的響應，將記錄數據存入臨時區(qū)塊中，還可以向發(fā)起操作的節(jié)點發(fā)送確認。

2.3)智能合約，計算機化的協(xié)議，可以執(zhí)行某個合約的條款，通過部署在共享賬本上的用于在滿足一定條件時而執(zhí)行的代碼實現，根據實際的業(yè)務需求代碼用于完成自動化的交易，例如查詢買家所購買商品的物流狀態(tài)，在買家簽收貨物后將買家的電子貨幣轉移到商戶的地址；當然，智能合約不僅限于執(zhí)行用于交易的合約，還可以執(zhí)行對接收的信息進行處理的合約。

3)區(qū)塊鏈，包括一系列按照產生的先后時間順序相互接續(xù)的區(qū)塊(Block)，新區(qū)塊一旦加入到區(qū)塊鏈中就不會再被移除，區(qū)塊中記錄了區(qū)塊鏈系統(tǒng)中節(jié)點提交的記錄數據。

參見圖2，圖2是本發(fā)明實施例提供的區(qū)塊結構(Block Structure)一個可選的示意圖，每個區(qū)塊中包括本區(qū)塊存儲交易記錄的哈希值(本區(qū)塊的哈希值)、以及前一區(qū)塊的哈希值，各區(qū)塊通過哈希值連接形成區(qū)塊鏈。另外，區(qū)塊中還可以包括有區(qū)塊生成時的時間戳等信息。

在分布式系統(tǒng)中，任何機器如服務器、終端都可以加入而成為節(jié)點，在硬件層面上，示例性地，參見圖3-1，圖3-1是本發(fā)明實施例提供的節(jié)點200的一個可選的軟硬件結構示意圖，節(jié)點200包括硬件層、中間層、操作系統(tǒng)層和應用層。然而，本領域的技術人員應當理解，圖3-1示出的節(jié)點200的結構僅為示例，并不構成對節(jié)點200結構的限定。例如，節(jié)點200可以根據實施需要設置較圖3-1更多的組件，或者根據實施需要省略設置部分組件。

節(jié)點200的硬件層包括處理器210輸入/輸出接口240，存儲介質230以及網絡接口220，組件可以經系統(tǒng)總線連接通信。

處理器210可以采用中央處理器(CPU)、微處理器(MCU，Microcontroller Unit)、專用集成電路(ASIC，Application Specific Integrated Circuit)或邏輯可編程門陣列(FPGA，Field－Programmable Gate Array)實現。

輸入/輸出接口240可以采用如顯示屏、觸摸屏、揚聲器等輸入/輸出器件實現。

存儲介質230可以采用閃存、硬盤、光盤等非易失性存儲介質實現，也可以采用雙倍率(DDR，Double Data Rate)動態(tài)緩存等易失性存儲介質實現，其中存儲有用以執(zhí)行上述通信狀態(tài)處理方法的可執(zhí)行指令。

網絡接口220向處理器210提供外部數據如異地設置的存儲介質230的訪問能力，示例性地，網絡接口220可以實現如基于碼分多址(CDMA，Code Division Multiple Access)、寬帶碼分多址(WCDMA，Wideband Code Division Multiple Access)等通信制式及其演進制式的通信。

驅動層包括用于供操作系統(tǒng)260識別硬件層并與硬件層各組件通信的中間件250，例如可以為針對硬件層的各組件的驅動程序的集合。

操作系統(tǒng)260用于提供面向用戶的圖形界面，顯示基于區(qū)塊鏈的各種應用處理的各種中間結果和最終結果。

應用層包括用于實現節(jié)點之間形成共識的共識機制270(用于在第一共識模式和第二共識模式中自適應切換)、以及節(jié)點基于分布式系統(tǒng)實現的功能如電子貨幣錢包280、智能合約290等，包括前述的第一共識模式和第二共識模式。

就應用層舉例來說，參見圖3-1，圖3-1提供的節(jié)點的應用層的共識機制270包括：

選舉單元2701，用于在第一共識模式中新的共識周期到達時，分布式系統(tǒng)中的節(jié)點通過執(zhí)行選舉操作處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)；其中，

主節(jié)點單元2702，用于當節(jié)點處于主節(jié)點的狀態(tài)時接收客戶端的消息，驗證消息的數字簽名，將消息發(fā)送到從節(jié)點；

從節(jié)點單元2703，用于當節(jié)點處于從節(jié)點的狀態(tài)時，接收到主節(jié)點發(fā)送的消息并向客戶端返回結果，驗證所接收的消息的數字簽名后向主節(jié)點發(fā)送確認接收通知；

主節(jié)點單元2702，用于當節(jié)點處于主節(jié)點的狀態(tài)時，接收到超出預定數量的從節(jié)點的確認接收通知，驗證確認接收消息的數字簽名后持久化存儲消息，向從節(jié)點發(fā)送存儲消息通知；

從節(jié)點單元2703，用于當節(jié)點處于從節(jié)點的狀態(tài)時，驗證所接收的存儲消息通知的數字簽名后持久化存儲所接收的消息；消息用于供客戶端確定異常節(jié)點。

在一個實施例中，從節(jié)點向客戶端返回結果攜帶消息的唯一性字段和從節(jié)點的數字簽名，用于供客戶端驗證所接收結果的數字簽名后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，確定不一致的唯一性字段對應的從節(jié)點為出錯節(jié)點，以及確定未返回相應結果的從節(jié)點為故障節(jié)點。

在一個實施例中，從節(jié)點所返回的結果還攜帶從節(jié)點所接收消息的序列號，用于供客戶端根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出不一致數量閾值時，判定主節(jié)點為惡意節(jié)點。

在一個實施例中，還包括切換單元2704，用于在客戶端確定主節(jié)點為惡意節(jié)點，或者，確定從節(jié)點中存在故障節(jié)點時，切換到第二共識模式

在一個實施例中，切換單元2704，還用于在切換到第二共識模式的準備階段，將節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向客戶端發(fā)送攜帶相應節(jié)點的數字簽名的一致性確認；

一致性確認，用于供客戶端在預定時間內接收到全部節(jié)點的一致性確認時，通知全部節(jié)點繼續(xù)切換到第一共識模式；未在預定時間內接收到全部節(jié)點的一致性確認時，通知全部節(jié)點繼續(xù)切換到第二共識模式。

在一個實施例中，切換單元2704，還用于在切換到第二共識模式的準備階段，將節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，確認一致時向消息的發(fā)送節(jié)點發(fā)送攜帶相應節(jié)點的數字簽名的數據確認；

數據確認，用于供客戶端在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認時，或在預定時間內任一節(jié)點未接收到其他節(jié)點發(fā)送的數據確認時，觸發(fā)分布式系統(tǒng)的節(jié)點繼續(xù)切換到第二共識模式。

在一個實施例中，主節(jié)點單元2702，還用于當節(jié)點處于主節(jié)點的狀態(tài)，并在第二共識模式中統(tǒng)計到與從節(jié)點針對所接收的消息形成共識的次數超過主節(jié)點共識次數閾值時，與從節(jié)點切換到第一共識模式。

在一個實施例中，主節(jié)點單元2702，還用于在第二共識模式中統(tǒng)計到針對所接收的消息形成共識的次數超過主節(jié)點共識次數閾值時，向從節(jié)點發(fā)送切換到第一共識模式的通知，并在接收到全部從節(jié)點發(fā)送的切換確認時，與從節(jié)點保持節(jié)點的狀態(tài)切換到第一共識模式。

在一個實施例中，從節(jié)點單元2703，還用于當節(jié)點處于從節(jié)點的狀態(tài)，在接收到切換到第一共識模式的通知時，統(tǒng)計到針對所接收的消息形成共識的次數超過從節(jié)點共識次數閾值時，向主節(jié)點發(fā)送切換確認。

在一個實施例中，選舉單元2701，還用于當未接收到主節(jié)點的心跳信息時，或者，主節(jié)點為惡意節(jié)點時，通過執(zhí)行選舉操作確定處于主節(jié)點的狀態(tài)或處于從節(jié)點的狀態(tài)。

在一個實施例中，選舉單元2701，還用于當在新的共識周期到達、且未接收到其他節(jié)點發(fā)送的心跳信息時，向其他節(jié)點發(fā)送選舉請求，選舉請求攜帶節(jié)點的數字簽名，當接收預定數量的其他節(jié)點返回的選舉確認時，轉換為主節(jié)點的狀態(tài)，定期向其他節(jié)點發(fā)送心跳信息；其中，選舉確認為其他節(jié)點驗證選取請求攜帶的數字簽名后發(fā)送；

選舉單元2701，還用于當在新的共識周期到達、且接收到其他節(jié)點發(fā)送的心跳信息時轉換為從節(jié)點的狀態(tài)。

在分布式系統(tǒng)中，客戶端是硬件以及在硬件上部署的軟件環(huán)境的結合，基于此，客戶端也可以稱為客戶端設備，用于實現挖礦、管理節(jié)點、部署智能合約等功能。

參見圖3-2，圖3-2是本發(fā)明實施例的客戶端的一個可選的軟硬件結構示意圖，客戶端300包括硬件層、中間層、操作系統(tǒng)層和應用層。然而，本領域的技術人員應當理解，圖3-2示出的客戶端300的結構僅為示例，并不構成對客戶端300結構的限定。例如，客戶端300可以根據實施需要設置較圖3-2更多的組件，或者根據實施需要省略設置部分組件。

客戶端300的硬件層包括處理器310輸入/輸出接口340，存儲介質330以及網絡接口320，組件可以經系統(tǒng)總線連接通信。

處理器310可以采用CPU、MCU、ASIC或FPGA實現。

輸入/輸出接口340可以采用如顯示屏、觸摸屏、揚聲器等輸入/輸出器件實現。

存儲介質330可以采用閃存、硬盤、光盤等非易失性存儲介質實現，也可以采用DDR實現，其中存儲有用以執(zhí)行上述通信狀態(tài)處理方法的可執(zhí)行指令。

網絡接口320向處理器310提供外部數據如異地設置的存儲介質330的訪問能力，示例性地，網絡接口320可以實現如基于CDMA、WCDMA等通信制式及其演進制式的通信。

驅動層包括用于供操作系統(tǒng)360識別硬件層并與硬件層各組件通信的中間件350，例如可以為針對硬件層的各組件的驅動程序的集合。

操作系統(tǒng)360用于提供面向用戶的圖形界面，顯示基于區(qū)塊鏈的各種應用處理的各種中間結果和最終結果。

應用層用于向分布式系統(tǒng)的節(jié)點發(fā)送消息，使各節(jié)點取得針對消息的共識從而持久化存儲消息；檢測分布式系統(tǒng)中的異常節(jié)點，觸發(fā)節(jié)點切換共識模式。

就應用層舉例來說，參見圖3-2，圖3-2提供了客戶端300的應用層的功能結構，包括管理節(jié)點380、部署智能合約390和共識370。

就共識370舉例來說，包括：

通信單元3701，用于向分布式系統(tǒng)的節(jié)點中的主節(jié)點發(fā)送消息，消息攜帶客戶端的數字簽名；

其中，數字簽名用于供主節(jié)點進行驗證，并將所接收的消息攜帶主節(jié)點的數字簽名，發(fā)送給分布式系統(tǒng)中的從節(jié)點；

通信單元3701，用于接收從節(jié)點在接收到消息時返回的結果；

檢測單元3702，用于根據從節(jié)點接收到消息時返回的結果，確定異常節(jié)點。

在一個實施例中，檢測單元3702，還用于驗證所接收結果的數字簽名后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，確定不一致的唯一性字段對應的從節(jié)點為出錯節(jié)點，以及確定未返回相應結果的從節(jié)點為故障節(jié)點。

在一個實施例中，檢測單元3702，還用于根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出不一致數量閾值時，判定主節(jié)點為惡意節(jié)點。

在一個實施例中，還包括：切換單元3703，用于確定主節(jié)點為惡意節(jié)點，或者，確定從節(jié)點中存在故障節(jié)點時，觸發(fā)分布式系統(tǒng)的節(jié)點切換到第二共識模式。

在一個實施例中，切換單元3703，還用于在預定時間內接收到全部節(jié)點的一致性確認時，通知全部節(jié)點返回第一共識模式；未在預定時間內接收到全部節(jié)點的一致性確認時，通知全部節(jié)點繼續(xù)切換到第二共識模式；

其中，一致性確認，為各節(jié)點在切換到第二共識模式的準備階段，將各節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較，并在確認一致時發(fā)送，且攜帶相應節(jié)點的數字簽名。

在一個實施例中，切換單元3703，還用于在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認時，或在預定時間內任一節(jié)點未接收到其他節(jié)點發(fā)送的數據確認時，觸發(fā)分布式系統(tǒng)的節(jié)點繼續(xù)切換到第二共識模式；

其中，數據確認，為各節(jié)點在切換到第二共識模式的準備階段，將各節(jié)點持久化存儲的消息的哈希值與其他節(jié)點持久化存儲的消息的哈希值比較并在確認一致時發(fā)送，且攜帶相應節(jié)點的數字簽名。

本發(fā)明實施例提供的分布式系統(tǒng)來說，其中的節(jié)點采用第一共識模式中對來自客戶端的消息形成共識，第一共識模式能夠保證節(jié)點形成共識的效率，當然，本發(fā)明實施例不排除分布式系統(tǒng)的節(jié)點默認采用第二共識模式對來自客戶端的消息形成共識。

對在第一共識模式中達成共識的實現方式進行說明，參見圖5，圖5是本發(fā)明實施例提供的分布式系統(tǒng)的節(jié)點在第一共識模式中達成共識、并檢測故障節(jié)點和惡意節(jié)點的一個可選的流程示意圖，包括以下步驟：

步驟101，分布式系統(tǒng)的多個節(jié)點在在第一共識模式中新的共識周期到達時，通過執(zhí)行選舉操作確定主節(jié)點的狀態(tài)、以及處于從節(jié)點的狀態(tài)。

在一個實施例中，分布式系統(tǒng)的節(jié)點具有三種類型(也稱為狀態(tài))：競爭節(jié)點、主節(jié)點和從節(jié)點；分布式系統(tǒng)的各個節(jié)點啟動計時器，在用于形成共識的新的共識周期到達時，各個節(jié)點均為競爭節(jié)點，各個競爭節(jié)點通過執(zhí)行選取操作而爭取轉換為主節(jié)點(一個分布式系統(tǒng)只有一個合法的主節(jié)點)，未成為主節(jié)點的競爭節(jié)點轉換為從節(jié)點。

對于每個競爭節(jié)點，在新的共識周期開始時會檢測是否接收到其他節(jié)點發(fā)送的心跳信息，如果沒有接收到，說明當前共識周期內還未產生主節(jié)點，則該競爭節(jié)點向其他節(jié)點發(fā)送選舉請求，在選取請求中攜帶發(fā)送節(jié)點的數字簽名，接收節(jié)點驗證選取請求的數字簽名成功后，確定選舉請求的可靠性，即向發(fā)送節(jié)點發(fā)送選舉確認，當一個節(jié)點接收到足夠(如預定數量可以為半數的節(jié)點)其他節(jié)點的選舉確認時即轉換為主節(jié)點，并定期向其他節(jié)點發(fā)送心跳信息，接收到心跳信息的競爭節(jié)點轉換為從節(jié)點。當在一個共識周期內任意節(jié)點都沒有接收的到足夠數量的選舉確認，則開始新的共識周期繼續(xù)選取操作直至確定主節(jié)點和從節(jié)點。

以第一共識模式采用RAFT算法為例，參見圖4，圖4是本發(fā)明實施例提供的在第一共識模式中各節(jié)點執(zhí)行選舉操作而確定主節(jié)點和從節(jié)點的一個可選的示意圖。

在分布式系統(tǒng)中，任何一個節(jié)點在任何一個時刻都處于三種狀態(tài)之一：主節(jié)點、從節(jié)點和競爭節(jié)點。在分布式系統(tǒng)正常運行的絕大部分時間，分布式系統(tǒng)中會有一個主節(jié)點,其他節(jié)點都是從節(jié)點，由主節(jié)點接受客戶端的消息。

分布式系統(tǒng)的工作時間分為連續(xù)的共識周期，這里也稱為任期(Term)，每個任期可以是任意時長，任期用連續(xù)的整數進行標號。每個任期首先進行主節(jié)點選舉，選舉時，多個競爭節(jié)點競爭成為主節(jié)點,一旦某個節(jié)點成為主節(jié)點,其他競爭節(jié)點則轉變?yōu)閺墓?jié)點，成為主節(jié)點的節(jié)點將在該任期內一致?lián)沃鞴?jié)點，如果該主節(jié)點發(fā)生故障，其他節(jié)點會在新的任期內進行選舉。

任何一個任期內都不會有多個主節(jié)點(除非有惡意節(jié)點偽裝為主節(jié)點)，每個節(jié)點都維護著當前任期的計數，每次節(jié)點間的之間的通信都包含任期的計數，每個節(jié)點在檢測到自己維護的任期計數低于其他節(jié)點維護的任期計數時，都會更新自己的任期計數為檢測到的最高的值。

當前一共識周期的主節(jié)點和競爭節(jié)點發(fā)現自己的任期計數低于別的節(jié)點的任期計數時，則立即把自己轉換為從節(jié)點，從而保證在每個任期內只有一個主節(jié)點。

RAFT算法中采用心跳機制觸發(fā)主節(jié)點選舉操作，當分布式系統(tǒng)啟動時，所有節(jié)點初始化為從節(jié)點狀態(tài)，設置任期為0，并啟動計時器，計時器超時后，從節(jié)點轉化為競爭節(jié)點，一旦轉化為競爭節(jié)點，執(zhí)行以下操作：

步驟1011，增加節(jié)點的任期的計數；

步驟1012，啟動一個新的計時器；

步驟1013，向其他節(jié)點發(fā)送選取請求(Request Vote)遠程過程調用協(xié)議(RPC，Remote Procedure Call Protocol)消息，并等待其他節(jié)點回復選舉確認。

如果在計時器超時前接收到多數節(jié)點的選舉確認，則轉換為主節(jié)點。如果接受到其他節(jié)點發(fā)送的附加內容為空的附加入口(Append Entries)心跳RPC消息，說明其他節(jié)點已經被選為主節(jié)點,則轉換為從節(jié)點。如果計時器超時還沒有接受到以上兩種信息中的任何一種，則進行新的選舉操作。

節(jié)點在接受到多數節(jié)點的投票成為主節(jié)點后，會立即向所有節(jié)點發(fā)送Append Entries心跳RPC消息，競爭節(jié)點收到Append Entries心跳RPC消息后，轉換為從節(jié)點，選舉操作結束。

步驟102，客戶端對消息進行數字簽名，發(fā)送攜帶數字簽名的消息給主節(jié)點。

客戶端使用自身的私鑰對消息的摘要(本發(fā)明實施例中不排除使用任意摘要算法從消息中提取摘要)加密，形成數字簽名。

步驟103，主節(jié)點驗證消息的數字簽名成功后，在消息中添加主節(jié)點的數字簽名，將消息發(fā)送到從節(jié)點。

主節(jié)點使用公鑰對數字簽名解密得到摘要，與采用摘要算法(與客戶端使用的摘要算法一致)進行比對，如果一致則說明消息的來源是可靠的，利用主節(jié)點的私鑰對消息的摘要加密形成主節(jié)點的數字簽名，在消息中添加主節(jié)點的數字簽名發(fā)送到各個從節(jié)點。對于消息攜帶的客戶端的數字簽名可以攜帶也可以不攜帶；如果主節(jié)點比對如果不一致可以丟棄消息并向客戶端要求重傳。

步驟104，從節(jié)點接收到主節(jié)點發(fā)送的消息后，驗證接收的消息的數字簽名，驗證通過后向主節(jié)點發(fā)送確認接收通知，并向客戶端發(fā)送結果。

從節(jié)點使用公鑰對接收的消息的數字簽名解密得到摘要，與采用摘要算法(與主節(jié)點使用的摘要算法一致)進行比對，如果一致則說明消息的來源是可靠的，利用從節(jié)點的私鑰對確認接收通知的摘要加密形成從節(jié)點的數字簽名，返回主節(jié)點。

從節(jié)點向客戶端發(fā)送結果包括兩種情況：

1)在當前共識周期內，如果從節(jié)點首次接收到主節(jié)點發(fā)送的消息，則向客戶端發(fā)送的結果包括：所接收消息的序列號；消息的唯一性字段(消息中的字段，能夠區(qū)別與其他消息的字段)；從節(jié)點針對結果的數字簽名，利用從節(jié)點的私鑰對結果的摘要進行加密得到。

2)在當前共識周期內，如果從節(jié)點非首次接收到主節(jié)點發(fā)送的消息，則向客戶端發(fā)送的結果包括：消息的唯一性字段(消息中的字段，能夠區(qū)別與其他消息的字段)；從節(jié)點針對結果的數字簽名，利用從節(jié)點的私鑰對結果的摘要進行加密得到。

步驟105，主節(jié)點驗證接收到確認接收通知攜帶的數字簽名，當連續(xù)接收到預定數量的從節(jié)點發(fā)送的確認接收通知后，持久化存儲消息，向從節(jié)點發(fā)送存儲消息通知。

存儲消息通知中攜帶主節(jié)點針對存儲消息通知的數字簽名，數字簽名為使用主節(jié)點的私鑰對存儲消息通知的摘要加密得到。

對于持久化存儲而言，主節(jié)點將消息以非易失的方式存儲，例如，在區(qū)塊鏈系統(tǒng)中，接收到客戶端提交的交易記錄的節(jié)點(主節(jié)點)將交易記錄存儲在區(qū)塊鏈的新區(qū)塊中。

步驟106，從節(jié)點接收到存儲消息通知，驗證攜帶的數字簽名成功后，在從節(jié)點本地持久化存儲消息，并向主節(jié)點發(fā)送攜帶數字簽名的存儲消息確認。

從節(jié)點使用公鑰對接收的存儲消息通知的數字簽名解密得到摘要，與采用摘要算法(與主節(jié)點使用的摘要算法一致)進行比對，如果一致則說明存儲消息通知的來源是可靠的，利用從節(jié)點的私鑰對存儲消息確認的摘要加密形成從節(jié)點的數字簽名，將攜帶數字簽名的存儲消息確認返回主節(jié)點。

步驟107，主節(jié)點對接收的存儲消息確認的數字簽名進行驗證，如果接收到超過半數的從節(jié)點的存儲消息確認并成功驗證數字簽名，向客戶端發(fā)送存儲消息確認。

主節(jié)點向客戶端發(fā)送的存儲消息確認中攜帶主節(jié)點的數字簽名，用于供客戶端驗證存儲消息來源的可靠性。

步驟108，客戶端主節(jié)點和從節(jié)點接收到消息時返回的結果，檢測異常節(jié)點：確定主節(jié)點是否為惡意節(jié)點，以及，確定從節(jié)點中是否存在故障節(jié)點。

在一個實施例中，客戶端驗證各個從節(jié)點返回的結果(各個從節(jié)點在接收到主節(jié)點發(fā)送的消息后發(fā))的數字簽名成功后，將所接收結果包括唯一性字段與所發(fā)送消息的唯一性字段比較，如果不一致，則判定發(fā)送不一致的唯一性字段的從節(jié)點為出錯節(jié)點，對于沒有返回結果的從節(jié)點則判定為故障節(jié)點。

在一個實施例中，當主節(jié)點為在一個新的共識周期內新產生的主節(jié)點時，當接收該主節(jié)點發(fā)送的消息時，從節(jié)點向客戶端發(fā)送的結果除了包括唯一性字段和數字簽名，還包括所接收消息的序列號，從而，客戶端能夠根據所接收結果攜帶的序列號與所發(fā)送消息的序列號比較，當發(fā)送不一致序列號的從節(jié)點的數量超出數量閾值時，說明新產生的主節(jié)點向從節(jié)點發(fā)送了偽造的消息，因此判定主節(jié)點為惡意節(jié)點。

從上述步驟可以看出，在第一共識模式中：

1)采用數字簽名的方式保證通信的可靠性：

對于任意通信的雙方均采用數字簽名的方式，即發(fā)送方在發(fā)送消息時會攜帶消息的數字簽名例如，使用發(fā)送方的不對稱加密算法的私鑰對消息的摘要進行加密，形成發(fā)送方的數字簽名，接收方通過驗證數字簽名確保消息的可靠性，即讀消息的簽名使用不對稱加密算法的公鑰(保證接收方和發(fā)送方使用相同的不對稱加密算法，則接收方預先獲知公鑰)進行解密，對解密得到的摘要與從消息中提取的摘要比對，如果一致說明數字簽名驗證通過，發(fā)送方發(fā)送的消息是可靠的。

2)從節(jié)點在接收主節(jié)點發(fā)送的消息時，會直接向客戶端返回結果，在結果中攜帶必要的信息如唯一性字段、消息序列號和數字簽名等，這樣，客戶端可以直接根據從節(jié)點返回的結果來判定從節(jié)點達成共識的情況，能夠容易地檢測出異常節(jié)點。

在第一共識模式中檢測到異常節(jié)點的情況，由于第一共識模式適用于保證節(jié)點的共識效率，而對節(jié)點異常的容錯形能有限，為此，本發(fā)明實施例提供在分布式系統(tǒng)中出現異常節(jié)點時使分布式系統(tǒng)切換到具有較佳容錯性能的第二共識模式的方案。

參見圖6，圖6是本發(fā)明實施例提供分布式系統(tǒng)在第一共識模式和第二模式中進行切換的一個可選的流程示意圖，包括以下步驟：

步驟109，客戶端確定分布式系統(tǒng)中存在異常節(jié)點時，觸發(fā)分布式系統(tǒng)中的節(jié)點從切換到第二共識模式。

當主節(jié)點為惡意節(jié)點、從節(jié)點中存在故障節(jié)點、或從節(jié)點中存在異常節(jié)點時，客戶端向分布式系統(tǒng)的節(jié)點廣播切換到第二共識模式的通知。

步驟110，分布式系統(tǒng)的節(jié)點在切換到第二共識模式的準備階段中，向其他節(jié)點發(fā)送相應節(jié)點持久化存儲的消息的哈希值以及數字簽名。

步驟111，消息的接收節(jié)點接收到分布式系統(tǒng)中全部其他節(jié)點(即，除接收節(jié)點之外的全部節(jié)點)發(fā)送的哈希值以及數字簽名，驗證哈希值的數字簽名成功后，將哈希值與接收節(jié)點持久化存儲的消息的哈希值進行比較，如果全部一致，則向客戶端發(fā)送一致性確認。

例如，分布式系統(tǒng)中接收到通知的節(jié)點1，在向第二共識模式切換的準備階段，將節(jié)點中持久化存儲的消息的哈希值以及數字簽名發(fā)送(如廣播)到節(jié)點2-N(N為分布式系統(tǒng)中節(jié)點的數量)，同時，節(jié)點1會接收節(jié)點2至節(jié)點N發(fā)送的哈希值，哈希值中攜帶相應節(jié)點的數字簽名，節(jié)點1驗證數字簽名成功后，將節(jié)點2至節(jié)點N發(fā)送的哈希值與節(jié)點1持久化存儲的消息的哈希值進行比較，如果全部一致，則節(jié)點1向客戶端發(fā)送一致性確認。

對于節(jié)點2至節(jié)點N來講，接收到哈希值的處理與節(jié)點1類似，不再重復說明。

步驟112，客戶端檢測是否接收到全部節(jié)點的一致性確認，如果是，則通知分布式系統(tǒng)的節(jié)點繼續(xù)切換到第一共識模式；如果否，則通知分布式系統(tǒng)的節(jié)點繼續(xù)切換到第二共識模式。

如果客戶端接收分布式系統(tǒng)中全部節(jié)點發(fā)送的一致性確認，說明之前檢測到異常節(jié)點是由于網絡波動或者丟棄響應消息導致的，分布式系統(tǒng)中不存在異常節(jié)點，因此重新切換到第一共識模式，保證節(jié)點之間達成共識的效率。

如果客戶端沒有在預定時間內接收分布式系統(tǒng)中全部節(jié)點發(fā)送的一致性確認，則說明分布式系統(tǒng)中確實存在異常節(jié)點，則通知分布式系統(tǒng)中節(jié)點繼續(xù)保持向第二共識模式的切換。

參見圖7，圖7是本發(fā)明實施例提供分布式系統(tǒng)在第一共識模式和第二模式中進行切換的一個可選的流程示意圖，包括以下步驟：

步驟109，客戶端確定分布式系統(tǒng)中存在異常節(jié)點時，觸發(fā)分布式系統(tǒng)中的節(jié)點從切換到第二共識模式。

當主節(jié)點為惡意節(jié)點、從節(jié)點中存在故障節(jié)點、或從節(jié)點中存在異常節(jié)點時，客戶端向分布式系統(tǒng)的節(jié)點廣播切換到第二共識模式的通知。

步驟110，分布式系統(tǒng)的節(jié)點在切換到第二共識模式的準備階段中，向其他節(jié)點發(fā)送相應節(jié)點持久化存儲的消息的哈希值以及數字簽名。

步驟113，消息的接收節(jié)點接收到分布式系統(tǒng)中其他節(jié)點發(fā)送的哈希值以及數字簽名，驗證哈希值的數字簽名成功后，將哈希值與接收節(jié)點持久化存儲的消息的哈希值進行比較，如果一致，則向消息的發(fā)送節(jié)點發(fā)送數據確認。

例如，分布式系統(tǒng)中接收到通知的節(jié)點1，在向第二共識模式切換的準備階段，將節(jié)點中持久化存儲的消息的哈希值以及數字簽名發(fā)送(如廣播)到節(jié)點2-N(N為分布式系統(tǒng)中節(jié)點的數量)，同時，節(jié)點1會接收節(jié)點2至節(jié)點N發(fā)送的哈希值，哈希值中攜帶相應節(jié)點的數字簽名，節(jié)點1驗證數字簽名成功后，將節(jié)點2至節(jié)點N發(fā)送的哈希值與節(jié)點1持久化存儲的消息的哈希值進行比較，如果全部一致，則節(jié)點1向節(jié)點2至節(jié)點N分別發(fā)送數據確認。

對于節(jié)點2至節(jié)點N來講，接收到哈希值的處理與節(jié)點1類似，不再重復說明。

步驟114，客戶端根據各節(jié)點發(fā)送的數據確認觸發(fā)分布式系統(tǒng)的節(jié)點返回第一共識模式，或，觸發(fā)分布式系統(tǒng)的節(jié)點繼續(xù)切換到第二共識模式。

對于分布式系統(tǒng)的各節(jié)點，將節(jié)點持久化存儲的消息的哈希值以及發(fā)送節(jié)點的數字簽名廣播到其他節(jié)點；對于哈希值的接收節(jié)點來說，在驗證所接收的哈希值的數字簽名后，將所接收的哈希值的與接收節(jié)點存儲消息的哈希值進行比較，在比較一致時向相應哈希值的發(fā)送節(jié)點發(fā)送數據確認，表示二個節(jié)點存儲的消息是一致的。

這里涉及到兩種情況：

情況1)在預定時間內，對于數據確認的接收節(jié)點來說，如果均接收到全部其他節(jié)點(除接收節(jié)點之外的節(jié)點)的發(fā)送的數據確認，則可以向客戶端發(fā)送數據確認，客戶端根據數據確認確認得知各節(jié)點存儲的消息是一致的，沒有必要繼續(xù)切換到第二共識模式，因此可以向分布式系統(tǒng)的各節(jié)點發(fā)送返回第一共識模式的通知，向第二共識模式切換的過程終止。

例如，節(jié)點1向節(jié)點2至節(jié)點N發(fā)送的哈希值，哈希值攜帶節(jié)點1的數字簽名，節(jié)點2至節(jié)點N-1在驗證節(jié)點1的數字簽名成功后，以節(jié)點2為例，節(jié)點2將節(jié)點2持久化存儲的消息的哈希值(對于區(qū)塊鏈系統(tǒng)中的節(jié)點來說，可以為區(qū)塊鏈中的最新的區(qū)塊的哈希值)與節(jié)點1發(fā)送的哈希值比較，如果一致則向節(jié)點1發(fā)送數據確認，對于節(jié)點3至節(jié)點N-1的處理與節(jié)點2類似。

假設節(jié)點1接收到節(jié)點2至節(jié)點N-1的數據確認，但是沒有接收到節(jié)點N的數據確認，由于客戶端在預定時間內沒有接收到節(jié)點1的數據確認，客戶端認為節(jié)點1未取得與全部其他節(jié)點的數據一致，則通知節(jié)點1至節(jié)點N繼續(xù)切換到第二共識模式的操作。

情況2)在預定時間內任一節(jié)點未接收到全部其他節(jié)點的數據確認時，或者，在預定時間內達成共識的節(jié)點未接收到未達成共識的節(jié)點的數據確認，導致客戶端未接收全部其他節(jié)點的數據確認，則客戶端通知分布式系統(tǒng)的節(jié)點繼續(xù)切換到第二共識模式。

例如，節(jié)點1向節(jié)點2至節(jié)點N發(fā)送的哈希值，哈希值攜帶節(jié)點1的數字簽名，節(jié)點2至節(jié)點N-1在驗證節(jié)點1的數字簽名成功后，以節(jié)點2為例，節(jié)點2將節(jié)點2持久化存儲的消息的哈希值(對于區(qū)塊鏈系統(tǒng)中的節(jié)點來說，可以為區(qū)塊鏈中的最新的區(qū)塊的哈希值)與節(jié)點1發(fā)送的哈希值比較，如果一致則向節(jié)點1發(fā)送數據確認，對于節(jié)點3至節(jié)點N-1的處理與節(jié)點2類似。

假設節(jié)點1在預定時間內接收到節(jié)點2至節(jié)點N-1的數據確認，但是沒有接收到節(jié)點N的數據確認，向客戶端發(fā)送在預定時間內沒有接收到全部節(jié)點數據確認的通知，客戶端通知節(jié)點1至節(jié)點N繼續(xù)切換到第二共識模式的操作。

再例如，節(jié)點1向節(jié)點2至節(jié)點N發(fā)送的哈希值，哈希值攜帶節(jié)點1的數字簽名，節(jié)點2至節(jié)點N-1在驗證節(jié)點1的數字簽名成功后，以節(jié)點2為例，節(jié)點2將節(jié)點2持久化存儲的消息的哈希值(對于區(qū)塊鏈系統(tǒng)中的節(jié)點來說，可以為區(qū)塊鏈中的最新的區(qū)塊的哈希值)與節(jié)點1發(fā)送的哈希值比較，如果一致則向節(jié)點1發(fā)送數據確認，對于節(jié)點3至節(jié)點N-1的處理與節(jié)點2類似。

假設節(jié)點1在預定時間內接收到節(jié)點2至節(jié)點N-1的數據確認，但是沒有接收到節(jié)點N的數據確認，則節(jié)點1向客戶端發(fā)送未接收到全部其他節(jié)點(也就是分布式系統(tǒng)中除節(jié)點1的之外節(jié)點)的數據確認的通知，客戶端通知節(jié)點1至節(jié)點N繼續(xù)切換到第二共識模式的操作。

繼續(xù)對分布式系統(tǒng)的節(jié)點切換到第二共識模式，并從第二共識模式切換的回第一共識模式的方式進行說明，對于從第二共識模式切換回第一共識模式，存在這樣的幾種方式：

方式1)主節(jié)點統(tǒng)計到形成共識的次數超出主節(jié)點共識次數閾值時，觸發(fā)從節(jié)點切換回第一共識模式，主節(jié)點和從節(jié)點在切換到第一共識模式中時繼承在第二共識模式中的節(jié)點狀態(tài)(即節(jié)點作為主節(jié)點或從節(jié)點的狀態(tài)保持不變)。

分布式系統(tǒng)處于第二共識模式中時，對于分布式系統(tǒng)中主節(jié)點(可以理解地，這里的主節(jié)點是針對一個共識周期而言)來說，如果主節(jié)點在第二共識模式中統(tǒng)計到與從節(jié)點針對所接收的消息達成共識的次數超過主節(jié)點共識次數閾值(如M次，M為根據對分布式系統(tǒng)中節(jié)點的共識的精度設定，一般地，精度要求越高，則預定次數越大)，說明主節(jié)點與從節(jié)點針對連續(xù)來自客戶端的消息已經達成較好的共識，為了進一步提升分布式系統(tǒng)的節(jié)點達成共識的效率，可以向從節(jié)點發(fā)送切換到第一共識模式的通知。

對于分布式系統(tǒng)中的從節(jié)點，在接收到主節(jié)點發(fā)送的切換到第一共識模式的通知后，即向主節(jié)點發(fā)送切換確認(承認主節(jié)點在切換到第一共識模式中時可以繼續(xù)保持主節(jié)點的狀態(tài))，主節(jié)點與從節(jié)為保持當前節(jié)點的狀態(tài)切換到第一共識模式，這樣在第一共識模式中可以避免惡意節(jié)點成為主節(jié)點的情況，確保共識的效率。

可以理解地，上述的共識節(jié)點數量閾值可以為分布式系統(tǒng)中的全部從節(jié)點的數量，或者，為分布式系統(tǒng)中在第一共識模式中要求達成共識的從節(jié)點的數量的最小值(即第一共識模式的容錯性能所要求的共識節(jié)點數量的最小值，低于該最小值后第一共識模式中達成的共識的可靠性無法得到保證)。

同理，上述的共識節(jié)點比例閾值可以對應分布式系統(tǒng)中的全部從節(jié)點的數量即100％，或者，為分布式系統(tǒng)中在第一共識模式中要求達成共識的從節(jié)點的數量的最小值如51％(即第一共識模式的容錯性能所要求的共識節(jié)點數量的最小值，低于該最小值后第一共識模式中達成的共識的可靠性無法得到保證)。

例如，分布式系統(tǒng)在第二共識機制中，假設節(jié)點1為主節(jié)點，節(jié)點2至節(jié)點N為從節(jié)點，各節(jié)點就來自客戶端的消息達成的共識進行計數，對于節(jié)點1來說，如果節(jié)點1與節(jié)點2至節(jié)點N就最近來自客戶端的M個(主節(jié)點共識次數閾值)消息均達成共識，說明各節(jié)點之間已經達成較好的共識，節(jié)點1會向節(jié)點2至節(jié)點N廣播切換到第一共識模式的通知，節(jié)點2至節(jié)點N向節(jié)點1發(fā)送切換確認，承認節(jié)點1在第一共識模式中仍然為主節(jié)點，節(jié)點2至節(jié)點2N繼續(xù)作為從節(jié)點，即使節(jié)點2至節(jié)點N中出現惡意節(jié)點，也無法偽造來自客戶端的消息，確保節(jié)點達成共識的效率。

方式2)主節(jié)點統(tǒng)計到形成共識的次數超出主節(jié)點共識次數閾值，主節(jié)點觸發(fā)從節(jié)點切換回第一共識模式，當從節(jié)點統(tǒng)計到形成共識次數閾值超出從節(jié)點共識次數閾值時，從節(jié)點確認切換回第一共識模式，主節(jié)點和從節(jié)點在切換到第一共識模式中時繼承在第二共識模式中的節(jié)點狀態(tài)(即節(jié)點作為主節(jié)點或從節(jié)點的狀態(tài)保持不變)。

分布式系統(tǒng)處于第二共識模式中時，主節(jié)點統(tǒng)計在第二共識模式中與其他節(jié)點(包括主節(jié)點和其他從節(jié)點)針對來自客戶端的消息形成共識的次數，如果形成共識的次數超過從節(jié)點共識次數閾值(可以小于或等于主節(jié)點共識次數閾值，例如，可以為M/2)，則向主節(jié)點發(fā)送同意主節(jié)點在第一共識模式中繼續(xù)作為主節(jié)點的通知，第二共識模式中的從節(jié)點在切換到第一共識模式中時繼續(xù)作為從節(jié)點，從而完成了切換到第一共識模式的選舉操作，并繼續(xù)在第一共識模式中針對來自客戶端的消息達成共識。這樣在第一共識模式中可以避免惡意節(jié)點成為主節(jié)點的情況，確保共識的效率。

在分布式系統(tǒng)的節(jié)點切換到第一共識模式之后，如果在第一共識模式中沒有檢測到異常節(jié)點，則繼續(xù)保持在第一共識模式，如果在返回第一共識模式后仍然無法取得較好的共識(例如，仍然檢測到惡意節(jié)點、異常節(jié)點或出錯節(jié)點)，則重新切換到第二共識模式。

這里的預定數量/比例可以根據前述說明而理解，不再重復說明。

例如，分布式系統(tǒng)的主節(jié)點可以基于計數器在切換到第二共識模式后同步開始計時，在計時時間達到計時時間閾值(如10分鐘，僅為舉例)后，會觸發(fā)分布式系統(tǒng)的從節(jié)點同步切換回第一共識模式，在第一共識模式中執(zhí)行選舉操作確定新的主節(jié)點和從節(jié)點；如果在切換到第一共識模式后仍然檢測到異常節(jié)點，則再次切換回第二共識模式(切換到第一共識模式的方式可以根據前述說明而理解)，從而，在利用第二共識模式進行共識以保證分布式系統(tǒng)的容錯性能的前提下，最大程度提升分布式系統(tǒng)達成共識的效率。

這里的預定數量/比例可以根據前述說明而理解，不再重復說明。

例如，分布式系統(tǒng)在第二共識機制中，假設節(jié)點1為主節(jié)點，節(jié)點2至節(jié)點N為從節(jié)點，各節(jié)點就來自客戶端的消息達成的共識進行計數，對于節(jié)點1來說，如果節(jié)點1與節(jié)點2至節(jié)點N就最近來自客戶端的M個(主節(jié)點共識次數閾值)消息均達成共識，說明各節(jié)點之間已經達成較好的共識，節(jié)點1會向節(jié)點2至節(jié)點N廣播切換到第一共識模式的通知，對于節(jié)點2至節(jié)點N來說，以節(jié)點2為例，節(jié)點2統(tǒng)計在第二共識模式中形成共識的次數，如果超出M/2，則向節(jié)點1發(fā)送切換確認(確認節(jié)點1在切換到第一共識模式中時仍然作為主節(jié)點，節(jié)點2作為從節(jié)點)；節(jié)點3至節(jié)點N的處理與節(jié)點2類似，不再重復說明。

當節(jié)點1接收到節(jié)點2至節(jié)點N中每個節(jié)點發(fā)送的切換確認時，切換到第一共識模式并在第一共識模式中，節(jié)點1作為主節(jié)點、節(jié)點2至節(jié)點N作為從節(jié)點；如果節(jié)點1未接收到節(jié)點2至節(jié)點N每個節(jié)點發(fā)送的切換確認，則繼續(xù)停留在第二共識模式，每間隔M/2次共識節(jié)點1繼續(xù)向節(jié)點2至節(jié)點N發(fā)送且切換到第一共識模式的通知，直至接收到節(jié)點2至節(jié)點N全部節(jié)點的切換確認。

下面，以區(qū)塊鏈系統(tǒng)(如維護對單獨的個人或實體開放的聯(lián)盟鏈系統(tǒng))在第一共識模式中采用改進的RAFT(T-RAFT)算法，在第二共識模式中采用PBFT算法進行共識為例，可以理解地，第一共識模式中還可以使用Paxos算法，第二共識模式中還可以采用BFT算法、BFT-RAFT等；第一共識模式可以采用任意共識效率高并且能檢測到節(jié)點故障或者拜占庭節(jié)點的算法如T-RAFT算法，第二共識模式可以采用任意可以實現拜占庭容錯的算法。

RAFT算法只解決了多個節(jié)點數據一致性的問題，并不解決拜占庭容錯，但是RAFT算法效率比較高。PBFT算法可以解決拜占庭容錯，但是由于在PBFT算法中需要在節(jié)點中進行消息廣播，實現的效率比較低。

在分布式網絡應用到聯(lián)盟鏈(對單獨的個人或實體開放的區(qū)塊鏈)的使用場景中，一般來說，區(qū)塊鏈系統(tǒng)在絕大部分時間里是沒有節(jié)點故障、也沒有拜占庭節(jié)點問題，采用RAFT的算法可以高效達成節(jié)點之間的共識。

只要在有節(jié)點出錯或者有拜占庭問題的時候，能夠自動采用要求PBFT算法實現各節(jié)點的共識，當所有節(jié)點都完全達成共識即沒有拜占庭節(jié)點的時候，再自動切換到共識效率較高的RAFT算法實現各節(jié)點間的共識。

RAFT解決了多個節(jié)點一致性的問題，效率比較高，但是沒有解決節(jié)點間拜占庭容錯的問題。

PBFT算法可以保證多個節(jié)點的一致性并且解決了各個節(jié)點間拜占庭容錯。

參見圖8，圖8是發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)采用RAFT算法達成共識的一個可選的流程示意圖，客戶端發(fā)送的消息主節(jié)點(leader節(jié)點)之后，主節(jié)點對接收的消息進行排序，按照排序分發(fā)給從節(jié)點(follower節(jié)點)，其他follower按照leader節(jié)點組織好的順序存儲消息到日志中，并向leader節(jié)點返回RPC結果(result)，然后leader節(jié)點將日志中消息存儲在本地磁盤后，再向各從節(jié)點發(fā)一次提交(commit)，則各從節(jié)點將消息中的日志存儲在從節(jié)點的本地磁盤中，就完成了消息的一致性同步，具有較高的效率，但是不能解決拜占庭節(jié)點的問題。

參見圖9，圖9是發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)采用PBFT算法達成共識的一個可選的流程示意圖，一個消息需要兩次廣播之后才能真正確認，由于依賴于廣播，在達成共識的過程發(fā)送的消息數是節(jié)點數的平方級別，因此實現共識的效率比較低，但是能解決節(jié)點間拜占庭容錯的問題。

RAFT算法雖然能解決一致性問題且效率高，但是不能解決拜占庭容錯問題，所以在很多區(qū)塊鏈系統(tǒng)的場景里是不被采納，而只能采納相對低效但是能解決拜占庭容錯的PBFT算法。本發(fā)明實施例充分利用在聯(lián)盟鏈的應用場景的特點：多數情況下網絡條件良好且無拜占庭節(jié)點，只需要多節(jié)點之間實現共識，結合RAFT的高效和PBFT的容錯優(yōu)點，提供了高效并且能解決拜占庭容錯問題自適應共識算法。

在應用于聯(lián)盟鏈的區(qū)塊鏈系統(tǒng)中，參與共識的節(jié)點個數有限，并且在絕大多數情況下各個參與節(jié)點沒有拜占庭節(jié)點，只需要保證數據一致性，此時采用效率較高的T-RAFT算法。當出現異常如節(jié)點間有拜占庭容錯需求或者節(jié)點故障的時候，能夠及時檢測到并且能夠自動切換到可以支持拜占庭容錯的PBFT算法，當PBFT算法中所有節(jié)點都達成共識的時候，再自動切換到效率較高的T-RAFT算法，這樣在絕大多數情況即網絡良好、無拜占庭節(jié)點的時，可以滿足聯(lián)盟鏈的高效共識的要求，有異常節(jié)點的時候又可以實時糾正、容錯。

為實現共識算法的自動切換，參見圖10，圖10是本發(fā)明實施例提供的實現自適應共識算法運行狀態(tài)圖，區(qū)塊鏈系統(tǒng)默認在T-RAFT算法下共識，T-RAFT算法檢測到數據不一致的節(jié)點低于閾值(全部節(jié)點數量，或預定比例的節(jié)點，根據T-RAFT算法的容錯性能設定)的時候，進入數據(消息)一致性的確認狀態(tài)：如果確認各節(jié)點的數據一致，再回到T-RAFT算法：如果節(jié)點的數據不一致，轉為PBFT算法實現節(jié)點之間的共識。當PBFT算法運行時檢測到所有節(jié)點的數據實現一致，再切換到T-RAFT算法。

T-RAFT算法是RAFT算法的改進，能夠防止節(jié)點篡改、重放、偽造消息，并且能夠及時發(fā)現惡意節(jié)點，參見圖11，圖11是本發(fā)明實施例提供的T-RAFT算法共識的實現示意圖，相對于RAFT算法而言，涉及的改進主要涉及以下幾個方面：

1、客戶端(Client)發(fā)送的消息中帶有針對消息的消息體的數字簽名，這樣可以防止消息在傳輸的過程中被修改，并且消息中攜帶唯一性字段，可以防止消息被截獲后重放。

2、各個節(jié)點間之間傳輸的消息攜帶發(fā)送方的數字簽名，消息的接收節(jié)點都會驗證數字簽名的正確性，這樣可以防止偽造新節(jié)點參與選舉操作或偽裝成主節(jié)點向從節(jié)點發(fā)送虛假的消息。

3、客戶端請求到主節(jié)點之后，T-RAFT共識模式中的主節(jié)點消息同步給從節(jié)點的過程中，所有的從節(jié)點收到主節(jié)點發(fā)送的消息之后，除了完成原RAFT的消息流程之外，都會向客戶端返回結果，返回結果中帶消息中的唯一性字段以及從節(jié)點的數字簽名。這樣客戶端就可以通過比較所有節(jié)點返回的結果，是否一致來判斷各節(jié)點數據(消息)的一致性。如果客戶端收到的結果不一致或者預定時間內未收到所有節(jié)點的結果，則判斷存在拜占庭節(jié)點或者存在故障節(jié)點，就會觸發(fā)數據一致性確認的流程。

數據一致性確認的過程發(fā)生在共識算法切換的中間階段，數據修復的過程實際上是一次少數服從多數的共識過程，共識的過程采用消息廣播的方式，具體來說，節(jié)點默認使用T-RAFT算法；在有節(jié)點出錯或者有拜占庭節(jié)點的時候，客戶端通過比較各個節(jié)點返回的結果可以發(fā)現數據不一致的情況，以判斷是否需要進行算法切換。

舉例來說，如需要切到PBFT算法的共識模式，客戶端向各節(jié)點廣播切換到PBFT算法的通知所有節(jié)點，當節(jié)點收到共識算法切換的通知而處于準備(prepare)階段的時候，廣播數據請求確認消息到所有其他的節(jié)點，數據請求確認消息攜帶節(jié)點的區(qū)塊鏈中最近共識的區(qū)塊的哈希值以及節(jié)點的數字簽名

收到數據請求確認消息的節(jié)點，這里稱為接收節(jié)點，會檢查節(jié)點的區(qū)塊鏈中最新的共識的區(qū)塊的哈希值跟數據請求確認消息攜帶的哈希值是否一致，并驗證節(jié)點數字簽名的正確性，對于接收節(jié)點來說，如果接收到所有其他節(jié)點的數據請求確認消息，并且這些數據請求確認消息簽名正確、且與接收節(jié)點最新共識的區(qū)塊的哈希值一致，則回復客戶端數據一致性確認，其中攜帶接收節(jié)點的數字簽名。

如果客戶端接收等到所有節(jié)點的數據一致性確認，則認為各節(jié)點維護的區(qū)塊鏈的數據是一致的，并且認為算法切換請求之前的數據一致性比對失敗是網絡波動或者丟棄響應消息導致的，就會重新切換到到T-RAFT算法。具體流程可以參考如下消息流程圖：

作為一個示例，參見圖12，圖12是本發(fā)明實施例提供的在PBFT算法切換的準備階段進行切換回T-RAFT算法的一個可選的流程示意圖，在圖12中，節(jié)點1、2、3、4都收到了來自其他節(jié)點的數據一致性確認的廣播消息，并且確認各節(jié)點最新共識的區(qū)塊的哈希值也一致，各節(jié)點都向客戶端返回數據一致性確認，并且各自返回T-RAFT算法的狀態(tài)，即使客戶端重新切換到T-RAFT的通知沒有到達節(jié)點，節(jié)點在超時時間到達之后也會進入T-RAFT算法的選舉流程。

如果在超時時間內客戶端沒有收到所有節(jié)點的數據一致性確認，或者共識節(jié)點(即區(qū)塊鏈系統(tǒng)中最新的區(qū)塊的哈希值一致)沒有收到其他所有節(jié)點數據一致性確認的廣播消息，則客戶端通知所有節(jié)點切換到PBFT算法。

另外，對于任一節(jié)點來說，如果沒有收到其他所有節(jié)點的數據一致性確認的廣播消息，會自動進入PBFT算法狀態(tài)，并廣播切換到PBFT算法的通知。

當節(jié)點收到f+1個以上的新算法廣播消息之后(f為根據PBFT算法在區(qū)塊鏈系統(tǒng)中能夠允許的出錯節(jié)點的最大值)，開始發(fā)起新算法(PBFT)中主節(jié)點的選舉，也稱為視圖更換(view change)，完成之后進入新的PBFT算法的共識階段。

參見圖13，圖13是本發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)從T-RAFT算法共識切換到PBFT算法共識的一個可選的流程示意圖，這個消息流程示意圖中，假設節(jié)點4故障，節(jié)點1、2和3收到客戶端的切換算法的通知而處于PBFT算法的切換準備階段時，分別廣播數據請求確認消息，消息中帶了自己最新共識的區(qū)塊塊的哈希值，由于4節(jié)點故障了，1、2、3節(jié)點在超時時間內不會接收到節(jié)點4廣播的數據一致性確認(一致響應)，所以不會向客戶端發(fā)送數據一致性確認，節(jié)點1、2、3和客戶端在超時之后，都會廣播切換到PBFT算法的通知，節(jié)點1、2、3都會收到算法切換的通知，大于f+1,最先收到f+1個算法切換通知的節(jié)點首先發(fā)起視圖更換流程，視圖更換完成之后，進入PBFT算法共識模式。

在PBFT的共識中，一旦主節(jié)點統(tǒng)計到連續(xù)出現M次(可配置)數據完全一致，會轉換為T-RAFT的競爭節(jié)點，并觸發(fā)T-RAFT的選舉過程，其他節(jié)點收到選舉請求之后，只要也統(tǒng)計到連續(xù)共識的次數大于M/2次或者大于一個固定的配置值T，就會同意競爭節(jié)點轉換為主節(jié)點，只有所有從節(jié)點都同意競爭節(jié)點轉換為主節(jié)點時，進入T-RAFT算法的共識模式，各節(jié)點的連續(xù)共識次數將清零。只要有一個從節(jié)點不同意競爭節(jié)點轉換為主節(jié)點，競爭節(jié)點馬上恢復到原有狀態(tài)即轉換為PBFT算法的主節(jié)點，繼續(xù)執(zhí)行PBFT算法，各節(jié)點的共識統(tǒng)計次數繼續(xù)累加，直到M+T的時候再次觸發(fā)一次T-RAFT選舉，如果不成功，下一次等到M+2T的時候觸發(fā)，如此往復，M+x*T的時候觸發(fā)，x是次數，直到主節(jié)點選舉成功為止。

參見圖14，圖14是本發(fā)明實施例提供的區(qū)塊鏈系統(tǒng)PBFT算法共識模式切換到T-RAFT算法共識模式的一個可選的流程示意圖，PBFT算法的過程中，主節(jié)點即節(jié)點1統(tǒng)計到數據連續(xù)一致(共識)超過M次的時候，轉變?yōu)門-RAFT的競爭節(jié)點狀態(tài)，然后發(fā)起T-RAFT算法的選舉，節(jié)點2、3和4收到選舉請求(request vote)消息之后，判斷是否也統(tǒng)計到連續(xù)數據一致的數量大于M/2(或者一個固定的值T)，如果是，則返回同意競爭節(jié)點轉換為主節(jié)點的切換確認。

競爭節(jié)點收到2，3，4節(jié)點的切換確認，轉換成主節(jié)點開始T-RAFT算法共識階段。在T-RAFT選舉的過程中，原來PBFT共識模式中的主節(jié)點(節(jié)點1)收到客戶端的消息之后，不再發(fā)送定序(PBFT算法中的pre-prepare)消息，等到選舉完成，在T-RAFT中將消息附在AppendEntries RPC中發(fā)送給從節(jié)點。

再結合實際應用中一個使用場景進行說明，參見圖15，圖15是本發(fā)明實施例提供的分布式系統(tǒng)應用于聯(lián)盟鏈系統(tǒng)的一個可選的場景示意圖，聯(lián)盟鏈系統(tǒng)是對單獨的個人或實體開放的，包括多個節(jié)點，每個節(jié)點向第三方支付機構、以及銀行業(yè)務系統(tǒng)(作為客戶端)提供接入，接收第三方支付機構、以及銀行業(yè)務系統(tǒng)提交的交易記錄，節(jié)點對提交的一個交易記錄形成共識后，才會將該交易記錄存儲在區(qū)塊鏈的最新區(qū)塊中存儲，供第三方支付機構和簽約銀行根據各自的業(yè)務流水進行對賬。

節(jié)點默認使用T-RAFT共識模式取得針對交易記錄的共識，在出現異常節(jié)點時切換到PBFT共識模式對交易記錄取得共識。

用戶的第三方支付終端中綁定了用戶在在銀行的信用卡賬戶，用戶與商家在線下或線上進行交易時，第三方支付終端可以通過預先獲得的信用卡賬號的預授權，從用戶的信用卡賬戶中劃款到商家的賬戶，形成一個交易記錄。

對于這筆交易來說，第三方支付機構的業(yè)務系統(tǒng)會在分布式系統(tǒng)中所接入的主節(jié)點提交一個交易記錄(例如，包括收款方、付款方和支付金額，攜帶第三方支付客戶端的數字簽名)；主節(jié)點對接收到交易記錄驗證數字簽名成功后，將交易記錄同步給其他的從節(jié)點(攜帶主節(jié)點的數字簽名)，從節(jié)點驗證交易記錄的數字簽名成功后，一方面向第三方支付機構業(yè)務系統(tǒng)返回結果(攜帶從節(jié)點數字簽名、唯一性字段，在主節(jié)點為新選舉出的主節(jié)點時，還攜帶交易記錄的序列號)；另一方面，通知主節(jié)點同步完畢；主節(jié)點在確認各從節(jié)點同步完成后將交易記錄存儲在區(qū)塊鏈的最新區(qū)塊中并通知各從節(jié)點，從節(jié)點執(zhí)行相同操作，完成交易記錄的持久化存儲。

對于上述針對交易記錄的共識過程，如果客戶端根據從節(jié)點返回的結果確定主節(jié)點為惡意節(jié)點，或從節(jié)點出現故障，則會觸發(fā)聯(lián)盟鏈系統(tǒng)切換到PBFT共識模式取得針對交易記錄的共識，確保交易記錄能夠在各節(jié)點的區(qū)塊鏈中順利存儲；根據聯(lián)盟鏈系統(tǒng)對第三方支付結構業(yè)務系統(tǒng)后續(xù)提交的交易記錄的共識情況，如取得較好的公式(主節(jié)點與其他節(jié)點連續(xù)M次共識)，可以切換回T-RAFT共識模式以提升共識的效率。

綜上，本發(fā)明實施例具有以下有益效果：

1)客戶端與節(jié)點之間、節(jié)點之間采用數字簽名的方式保證通信的可靠性，避免消息偽裝的情況，保證分布式系統(tǒng)內部通信的可靠性。

2)從節(jié)點在接收主節(jié)點發(fā)送的消息時，會直接向客戶端返回結果，在結果中攜帶必要的信息如唯一性字段、消息序列號和數字簽名等，這樣，客戶端可以直接根據從節(jié)點返回的結果來判定從節(jié)點達成共識的情況，能夠容易地檢測出異常節(jié)點。

3)在檢測到異常節(jié)點時，能夠從默認的共識效率高的第一共識模式切換到容錯性能更優(yōu)的第二共識模式，確保分布式系統(tǒng)的共識在出現異常時也能夠順利達成。

4)在第二共識模式中一旦達成較好的共識(例如，根據共識次數判斷)，則再次切換到第一共識模式，這種自適應的共識模式切換實現了共識效率和容錯性能的最佳融合。在分布式系統(tǒng)的運行的網絡狀態(tài)良好的多數時間內、實現了共識效率高的技術效果，節(jié)點故障或者有拜占庭容錯節(jié)點時保真分布式系統(tǒng)的業(yè)務功能正常處理。

本領域的技術人員可以理解：實現上述方法實施例的全部或部分步驟可以通過程序指令相關的硬件來完成，前述的程序可以存儲于一計算機可讀取存儲介質中，該程序在執(zhí)行時，執(zhí)行包括上述方法實施例的步驟；而前述的存儲介質包括：移動存儲通信狀態(tài)處理裝置、隨機存取存儲器(RAM，Random Access Memory)、只讀存儲器(ROM，Read-Only Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質。

或者，本發(fā)明上述集成的單元如果以軟件功能模塊的形式實現并作為獨立的產品銷售或使用時，也可以存儲在一個計算機可讀取存儲介質中。基于這樣的理解，本發(fā)明實施例的技術方案本質上或者說對相關技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機通信狀態(tài)處理裝置(可以是個人計算機、服務器、或者網絡通信狀態(tài)處理裝置等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分。而前述的存儲介質包括：移動存儲通信狀態(tài)處理裝置、RAM、ROM、磁碟或者光盤等各種可以存儲程序代碼的介質。

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，可輕易想到變化或替換，都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應以所述權利要求的保護范圍為準。