Fabric中資料同步的實現

2021-09-25 03:11:45 字數 4452 閱讀 4718

1.hyperledger fabric 中資料傳輸的實現

hyperledger fabric 是乙個由n個節點組成的分布式網路,且 hyperledger fabric 通過把網路內的節點分解為執行交易(背書和提交)節點和交易排序節點,利用這些分解後的節點來優化區塊鏈網路效能及安全性和可擴充套件性。但是分解之後網路需要乙個安全、可靠、可擴充套件的資料分發協議來保證資料的完整性和一致性。為了滿足這些要求,hyperledger fabric 中使用了 gossip 資料分發協議。

8.2.1 hyperledger fabric中的gossip

fabric 中 的各個 peer 節點之間利用 gossip 協議來完成區塊廣播以及狀態同步的過程。gossip 訊息是連續的,通道上的每個 peer 節點都不斷地接收來自多個節點已完成一致性的區塊資料。每條傳輸的 gossip 訊息都有相應的簽名,從而由拜占庭參與者傳送的偽造訊息很容易地識別來,並且可以防止將訊息分發給不在同一通道中的其它節點。受到延遲、網路分割槽或其他導致區塊丟失的原因影響的節點,最終將通過聯絡已經擁有這些缺失區塊的節點,與當前賬本狀態進行同步。

在 hyperledger fabric 網路中基於 gossip 的資料傳播協議在 fabric 網路上執行三個主要功能:

1.通過不斷識別可用的成員節點並最終監測節點離線狀態的方式,對節點的發現和通道中的成員進行管理。

2.將分類帳本資料傳播到通道上的所有節點。任何節點中如有缺失區塊都可以通過從通道中其它節點複製正確的資料來標識缺失的區塊並同步自身。

3.在通道上的所有節點上同步分類帳狀態。通過允許點對點狀態傳輸更新賬本資料,保證新連線的節點以最快的速度實現資料同步。

基於 gossip 的廣播由節點接收來自通道內其他節點的訊息,然後將這些訊息**給隨機選擇的且在同一通道內的若干個鄰居節點,這種迴圈不斷重複,使通道中所有的成員節點的賬本和狀態資訊不斷保持與當前的最新狀態同步。對於新區塊的傳播,通道上的 leader peer 節點從 ordering 服務中提取資料,並向隨機選擇的鄰居節點發起 gossip 傳播。

隨機選擇的鄰居節點數量可以通過配置檔案進行配置宣告。節點也可以使用拉取機制,而不是等待訊息的傳遞。

正如上圖所示,客戶端應用程式將交易提案請求提交給背書節點(endorse peer),背書節點處理並背書簽名後返回響應,然後提交給 ordering 服務進行排序,排序服務達成共識後生成區塊,通過 deliver廣播給各個組織中通過選舉方式選擇的作為代表能夠連線到排序服務的 leader peer 節點,leader peer 節點隨機選擇n個節點將接收到的區塊進行分發。另外,為了保持資料同步,每個節點會在後台周期性地與其它隨機的n個節點的資料進行比較,以保持區塊資料狀態的同步。

在 hyperledger fabric 網路中,每乙個組織都會通過領導選舉機制選擇乙個節點(leader peer),該節點將保持與 ordering 服務的連線,並在其所在組織的節點之間分發從 ordering 服務節點接收到的新區塊。利用領導人選舉為系統提供了有效利用 ordering 服務頻寬的能力。在 hyperledger fabric 中實現領導人選舉有兩種方式:

1.靜態選舉:由系統管理員手動配置實現,指定組織中的乙個 peer 節點作為領導節點代表組織與 ordering 服務建立連線。

2.動態選舉:通過執行領導人選舉程式,動態從組織中選擇乙個 peer 節點成為領導者節點,從ordering 服務中拉出區塊,並將塊分發給組織中的其他 peer 節點。

靜態選舉

使用靜態領導選舉可以通過在配置檔案中指定相關的引數來實現。可以定義乙個節點為 leader peer,也可定義多個節點或組織內所有節點都為 leader peer。

實現靜態選舉機制,需要在 core.yaml 中配置以下引數:

動態選舉

動態領導選舉可以在各個組織內各自動態選舉乙個 leader 節點,它將代表各個連線到 ordering 服務並拉出新的區塊。

當選的 leader 節點必須向組織內的其他節點定期傳送心跳資訊,作為處於活躍的證據。如果一名或多名節點在指定的一段時間內得不到最新訊息,網路將啟動新一輪領導人選舉程式,最終選出新的 leader 節點。

啟用動態選舉機制,需要在 core.yaml 中配置以下引數:

錨節點主要用於啟動來自不同組織的節點之間的 gossip 通訊。錨節點作為同一通道上的另一組織的節點的入口點,可以與目標錨節點所在組織中的每個節點通訊。跨組織的 gossip 通訊必須包含在通道的範圍內。

由於跨組織的通訊依賴於 gossip,某乙個組織的節點需要知道來自其它組織的節點的至少乙個位址(從這個節點,可以找到該組織中的所有節點的資訊)。所以新增到通道的每個組織應將其節點中的至少乙個節點標識為錨節點(也可以有多個錨節點,以防止單點故障)。網路啟動後錨節點位址儲存在通道的配置塊中。

可以通過在 configtx.yaml 配置檔案指定錨節點:

8.2.2 fabric的資料同步實現

hyperledger fabric 是乙個分布式區塊鏈網路,所有的 peer 節點都會儲存共享分類帳的副本(即所有事務的確切歷史記錄)。當新區塊產生後必須通過分布式網路,使分類帳的副本在所有節點之間保持同步。

在較高的層次上,該過程如下所示:

但在hyperledger fabric 網路中實際發生的情況是,ordering 服務只向每個組織中的單個節點(leader peer)提供新的區塊。通過 gossip 的過程, peer 節點自己完成了將新區塊傳播到其它 peer 節點的工作:

上面的過程稱之為廣播,它是一種基於推送(push-based)的方式,通過網路傳輸資訊,fabric 的 gossip 系統使用它來向所有 peer 節點分發訊息。

gossip 協議的關鍵組成部分是每個節點將訊息隨機選擇並**給網路中其它節點。這意味著每個節點都知道網路中的所有節點,因此可以在相應的 peer 節點中進行選擇。那麼,某乙個節點是如何知道組織內的所有節點呢?並且如果有 peer 節點與網路斷開連線並在後期重新連線,則它將錯過廣播過程。

在 hyperledger fabric 中,每個節點都會隨機性的向預先定義數量的其它節點定期廣播一條訊息,指示它仍處於活動狀態並連線到網路。每個節點都維護著自己的網路中所有節點的列表(處於活躍的節點和無響應的節點)。

這種情況之下需要乙個基於拉取(pull-based)的實現機制來向其它 peer 節點請求它丟失的資料。在hyperledger fabric中, peer 節點之間定期相互交換成員資格資料( peer 節點列表,活動和死亡)和分類帳本資料(事務塊)。在這種機制下, peer 節點即使因為故障或其它原因導致錯過了接收新區塊的廣播或因為其它原因產生了缺失區塊,但仍然在加入網路之後可以與其它的 peer 節點交換資訊以保持資料同步。

正如上圖所示,hyperledger fabric使用對等體之間的 gossip 作為容錯和可擴充套件機制,以保持區塊鏈分類賬的所有副本同步,它減少了orderer 節點上的負載。由於不需要固定連線來維護基於gossip的資料傳播,因此該流程可以可靠地為共享賬本保證資料的一致性和完整性,包括對節點崩潰的容錯。

另外,某些節點可以加入多個不同的通道,但是通過將基於節點通道訂閱的機制作為訊息分發策略,由於通道之間實現了相互隔離,乙個通道上的節點不能在其他通道上傳送或共享資訊,所以節點無法將區塊傳播給不在通道中的節點。

點對點訊息的安全性由節點的tls層處理,不需要簽名。節點通過其由ca分配的證書進行身份驗證。節點在gossip層的身份認證會通過tls證書體現。賬本中的區塊由排序服務進行簽名,然後傳遞給通道中的領導者節點。

身份驗證過程由節點的成員管理服務的提供者(msp)進行管理。當節點第一次連線到通道中的時候,tls會話將與成員身份繫結。這本質上是通過網路和通道中的成員身份對連線的每個節點進行身份驗證。

1.如何將多個 peer 節點定義為 leader 節點?

靜態指定方式可以將多個 peer 節點定義為 leader 節點,將配置檔案中需要指定為 leader 節點的所屬 peer 配置的 environment 中的兩項引數值設定如下:

但在實際的生產環境中,使用太多的 leader 節點連線到 ordering 服務可能會降低網路頻寬利用率, 所以不推薦同乙個組織中設定多個 leader 節點。

2.組織內的其它 peer 節點可以與 ordering 服務直接通訊嗎?

組織內的節點除了 leader 節點, 其它所有的 peer 節點都不能夠與 ordering 服務直接通訊。

fabric 節點同步資料出現同步一會就停止同步

起因 節點因各種原因導致節點容器停掉,這個時候啟動節點 按理說應該會同步節點在停掉漏掉的資料,結果發現發現同步過程 現 同步一會就停止,如果不斷重新啟動也是斷斷續續同步。這篇文章幫你找到原因 其實原因很簡單 主要是peer配置問題 peer0 container name peer0.org1.ex...

SQL SERVER中資料同步的實現 轉

轉自 sqlserver中,資料庫同步的實現 經過測試,可以順利實現資料庫結構的初始化和資料的單向同步 也就是訂閱伺服器的資料可以及時更新為發布伺服器的資料 準備工作 資料的同步中主要考慮的三部分,可以理解成三颱主機。發布伺服器,分發伺服器和訂閱伺服器 可以從字面的意思理解,要實現的功能實際就是讓訂...

Fabric中的ACLs相關

什麼是acls fabric uses access control lists acls to manage access to resources by associating apolicy which specifies a rule that evaluates to true or fa...