理解分布式一致性:拜占庭容错与PBFT
理解分布式一致性:拜占庭容錯與PBFT
- 拜占庭問題
- 拜占庭容錯BFT
- PBFT（Practical Byzantine Fault Tolerance）
- why 3f+1 ？
- PBFT 的優點
- PBFT 的缺點
之前的幾篇文章我們講了分布式協議里面的Paxos協議和Raft協議。這兩個協議主要適用于可信節點的情況，所謂可信節點就是節點只會出現因為系統或者網絡問題的宕機情況，不會有惡意節點。
那么如果有惡意節點的情況下，我們怎么去達成共識呢？一個很簡單的辦法就是少數服從多數，下面我們看一下拜占庭是做的。
拜占庭問題
先看一下我們要解決的問題，也叫做拜占庭將軍問題。
話說有一天有n個拜占庭將軍相約于魔法師大峽谷中，他們的目標就是推掉對方的塔。塔有點強大，只有不少于m個將軍同時去推塔才能成功，如果一個一個的去推塔，就免不了身死道消的結果。那時候他們的微信版本還比較低，不能建群聊天，只能一對一的通信。
將軍之間并不是表面上看起來的一條心，假如一個將軍想組織大家在下午兩點鐘去偷塔，那需要怎么樣操作才能保證不少于m個將軍同時執行”兩點鐘偷塔“這個命令呢？
這個問題就叫做拜占庭將軍問題，是指在不可信任環境下的分布式一致性問題。
這里我想強調一點，分布式一致性是指各個節點之間的數據同步一致，跟數據正確與否沒有關系。
拜占庭容錯BFT
拜占庭容錯是分布式協議的一種屬性，如果這種協議可以解決不可信任環境下的分布式一致性問題，那么它就是拜占庭容錯。
PBFT（Practical Byzantine Fault Tolerance）
PBFT是拜占庭容錯的一種實現。它的性能很高并且低延時，能夠解決不信任節點的問題。
其有如下幾個特征：
1. 同一時間只有一個Leader向外發送消息，其它節點只是被動接收消息。
2. 所有的節點互相之間通信，并且將其收到的消息轉發給其他節點，從而達成多數共識。
3. 節點之間的消息需要保證：A：節點收到的消息確實是某個節點轉發的。B：消息在發送過程中不會被篡改。
如果想讓PBFT正常工作，那么惡意節點個數不能大于總節點個數的1/3。
正常來講，節點個數越多，惡意節點所占有的比率就會越低，系統就會越穩定，但是因為所有的節點之間需要兩兩通信，節點個數的增多會帶來節點之間通信的壓力。
下面看下PBFT的工作流程：
這里Leader是隨機選擇出來的，如果選出來的Leader在給定的時間內并沒有發出廣播，那么系統會自動挑選新的Leader并進入下一輪。
why 3f+1 ？
很多同學可能不理解為什么對于f個惡意節點來說，至少要3f+1個節點才能正常工作。這里給大家解釋一下。
之前在Paxos和Raft協議里面，我們給大家講過在可信任節點的環境里面，達成共識的條件是收到的消息需要>n/2 ，即要收到大多數節點的反饋才能表示共識完成。
那么在有不可信節點f的情況下，我們的可信任節點個數是n-f個，我們收到的可信任節點個數的反饋必須>(n-f)/2才表示絕大多數可信任節點已經收到消息了。同時我們也可能收到f個不信任節點發來的消息，那么當（n-f)/2 > f 的時候，根據多數原則，我們可以區分出哪些是信任消息，哪些是不可信任消息，因此得出 n> 3f .
PBFT 的優點
PBFT 的缺點
說完優點說缺點。其實前面我們也提到了，PBFT需要節點之間兩兩通信，當節點個數太多的話，節點之間通信的消耗會大大增加。所以PBFT只適合用在聯盟內部少數節點的情況。像是Hyperledger這樣的聯盟鏈。
同時，PBFT也可能會受到女巫攻擊（Sybil attack），這個后面我們有時間再單獨講。
更多精彩內容且看：
- 區塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續更新
- Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續更新
- Spring 5.X系列教程:滿足你對Spring5的一切想象-持續更新
- java程序員從小工到專家成神之路（2020版）-持續更新中,附詳細文章教程
更多教程請參考flydean的博客
總結
以上是生活随笔為你收集整理的理解分布式一致性:拜占庭容错与PBFT的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 理解分布式一致性:Paxos协议之Gen
- 下一篇： 女巫攻击及其防范