什麼是區塊鏈的共識機制？

說到區塊鏈，我們必然會談及它的共識機制。那麼今天我來給大家分享下什麼是區塊鏈的共識機制。

要使區塊鏈稱為一個難以攻破、公開的、不可篡改數據記錄的去中心化誠實可信系統，需要在儘可能短的時間內做到分佈式數據記錄的安全、明確及不可逆，提供一個最堅實且去中心化的系統。在實踐中，該流程分為兩個方面：一是選擇一個獨特的節點來產生一個區塊，二是使用分佈式數據記錄不可逆。實現上述流程的技術核心機制就是共識機制。共識機制是區塊鏈節點就區塊信息達成全網一致共識機制，可以保證最新區塊被準確添加至區塊鏈，節點存儲的區塊信息一致不分叉，甚至可以抵禦惡意攻擊。

當前主流的共識機制包括：Raft協議、PoW（Proof of Work）、PoS（Proof of Stake）、PoW+PoS混合機制，我們在這裡詳細介紹一下。

一、Raft協議

根據資料，Raft是斯坦福的Diego Ongaro、John Ousterhout兩個人以易懂為目標設計的一致性算法，2014年發佈論文In search of an Under-standable Consensus Algorithm，到現在已經有了十多種語言的Raft算法實現框架。其中比較出名的有etcd，Google的k8s也是用了ectd作為服務發現框架，可見易懂性是多麼重要。與Paxos不同，Raft強調的是易懂，Raft和Prxos一樣只要保證n/2+1節點正常就能夠提供服務，眾所周知，當問較為複雜時候可以把問題分解成幾個小問題來處理，這裡先簡單介紹一下Raft的工作流程，如圖所示。

Raft開始在及群眾選舉出Leader（俗稱老大）負責日誌複製的管理，Leader接收來自客戶端的事物請求（日誌），並將它們複製給集群的其他節點，然後負責通知集群中其他節點提交日誌，Leader負責保證其他節點與他的日誌同步，當Leader死機後集群其他節點會發起選舉，選出新的Leader。Raft把集群中的節點分文三種狀態：Leader、Follower、Candidate。當然每種狀態負責的任務是不一樣的，Raft在運行時提供的服務只存在Leader和Follower兩種狀態。

Leader（老大）：負責日誌的同步管理，處理來自客戶端的請求，與Follower保持著HeartBeat的聯繫。

Follower（追隨者）：剛啟動時所有節點為Follower狀態，響應Leader的日誌同步請求，響應Candidate的請求，並把請求到的Follower的事務轉發給Leader。

Candidate（候選者）：負責選舉投票Raft剛啟動時由一個節點從Follower轉為Candidate發起選舉，選舉出Leader後從Candidate轉為Leader狀態。

在Raft中使用了一個可以理解為週期（第幾屆，任期）的概念，用Term作為一個週期，每個Term都是一個連續遞增的編號，每一輪選舉都是一個Term週期，在一個Term中只能產生一個Leader。在這裡先描述一下Term的變化過程：Raft開始所有Follower的Term為1，其中一個Follower邏輯時鐘到期後轉換為Candidate，Term加1，這是Term為2（任期）；然後開始選舉，這時候有幾種情況會使Term發生改變。1⃣️如果當前Term為2的任期內沒有選舉出Leader或出現異常，則Term遞增，開始新一任期選舉；2⃣️當本輪Term為2的週期選舉出Leader後，Leader就死機了，然後qitaFollower轉為Candidate，Term遞增，開始新一任期選舉；3⃣️當Leader或Candidate發現自己的Term比Follower小時，Leader或Candidate將轉換Follower，Term遞增；4⃣️當Follower的Trem比別的Term小時，Follower將更新Term保持與其他Follower一致。可以說每次Term的遞增都將發生新一輪的選舉，Raft保證了一個Term只有一個Leader，在Raft正常運轉中所有節點的Term都是一致的，如果節點不發生故障則Term（任期）會一致爆出下去，當某節點收到請求中Term比當前Term小時，則拒絕請求。

Raft的選舉有定時器來觸發，每個節點的選舉定時器時間都是不一樣的，開始狀態都為Follower，某個節點定時器觸發選舉後Term遞增，狀態由Follower轉為Candidate，向其他幾點發起RequestVote RPC請求，這時候將有三種可能的情況發生：1⃣️該RequestVote請求接收到n/2+1（過半數）個節點的投票，從Candidate轉為Leader，向其他節點發送HeartBeat以保持Leader的正常運轉；2⃣️在此期間如果接收到其他節點發過來的AppendEntries RPC請求，如該節點的Term大，則當前節點轉為Follower，否則保持Candidate拒絕該請求；3⃣️Election timeou發生則Term遞增，重新發起選舉。在一個Term期間每個節點只能投票一次，所有當有多個Candidate存在時就會出現每個Candidate發起的選舉都存在接收到的投票數都不過半的問題，這時候每個Candidate都將Term遞增，重啟定時器，並重新發起選舉。由於每個節點中定時器的時間都是隨機的，所以就不會多次存在多個Candidate同時發起投票的問題。有以下幾種情況會發起選舉：1⃣️Raft初次啟動，不存在Leader，發起選舉；2⃣️Leader死機或Follower沒有接收到Leaser的HeartBeat，發生Election timeout從而發起選舉。日誌複製的主要作用是用於保證幾點的一致性，這階段所做的操作也是為了保證一致性與高可用性。當Leader選舉出來後，便開始負責客戶端的請求，所有事務（更新操作）請求都必須先經過Leader處理，這些事務請求或命令就是這裡說的日誌，都知道要保證幾點的一致性就要保證每個幾點都按順序執行相同的操作序列，日誌複製就是為了保證執行相同操作所做的工作。在Raft中，當接收到客戶端的日誌（事務請求）後先把該日誌追加到本地的Log中，然後通過HeartBeat把該Entry同步給其他Follower，Follower接收到日誌記錄後向Leader發送ACK。dangLeader收到大多數（n/2+1個）Follower的ACK信息後，將該日誌設置為已提交併追加到本地磁盤中，通知客戶端，並在下個HeartBeat中Leader將通知所有的Follower將該支持存儲在自己的本地磁盤中