lamport演算法

❶ Chandy-Lamport分布式快照演算法小記

前面陸陸續續寫了幾篇關於Flink的淺顯的小文章，其中多次提到了「非同步屏障快照（asychronous barrier snapshot, ABS）演算法」這個詞，並指出它是Flink檢查點機制的基礎。而ABS演算法的淵源就是本文要說的Chandy-Lamport演算法，它是目前在流式系統中廣泛使用的分布式快照演算法。

這個演算法在論文 《Distributed Snapshots: Determining Global States of Distributed Systems》 中提出，並以作者的名字命名，即得州大學奧斯汀分校的K. Mani Chandy與斯坦福的Leslie Lamport（這位也是鼎鼎大名的Paxos演算法的作者）。演算法產生的背景有點意思，據Leslie Lamport自己說：

下面先介紹一些分布式系統中快照的前置知識，然後正式介紹Chandy-Lamport演算法。

所謂分布式快照，實際上就是特定時間點記錄下來的分布式系統的全局狀態（global state）。分布式快照的主要指跡此用途有故障恢復（即檢查點）、死鎖檢測、垃圾收集等。

為了方便理解，我們仍然沿用原論文中的方法，將分布式系統抽象為一張有向圖：頂點稱為進程（process），邊稱為鏈路（channel）。下圖就示出包含3個進程和4個鏈路的分布式系統。

那麼， 全局狀態就要包含所有進程的狀態以及所有鏈路的狀態 。由於進程之間在通過鏈路不停地交換數據，所以以下動作都可能造成全局狀態的改變：

論文中將使分布式系統狀態發生變化的因素叫做事件（event），並給出了它的形式化定義，即e=<p, s, s', M, c>。p、M、c的定義上面已經提到了，而s和s'分別是進程p在事件e發生之前及發生之後的狀態。

可見，進程對自己的狀態是有感知的，而鏈路本身只負責傳遞消息，它們的狀態不容易記錄。並且我們 無法讓時間靜止 ，各個進程的時鍾也很有可能不同步，故不能在一瞬間同時捕獲所有進程和鏈路的狀態。所以必須要曲線救國，通過 每個進程記錄的與自己相關的狀態合並出全局狀態 ，這也是Chandy-Lamport演算法的核心思想所在。

下面具體介紹演算法的細節。

Chandy-Lamport演算法基於如下前提：在每對進程p i 、p j 之間都存在兩條單向的鏈路c ij 和c ji ，即對於p i 來講，c ij 是出邊，c ji 是入邊。鏈路的網路可靠，緩存無限大，並且先進先出，即鏈路上的消息會不重不漏地按序到達。

演算法要達到如下的終極目標：

為了保證成功取得全局快照，Chandy-Lamport演算法分為3個階段，即初始化快照、擴散快照與完成快照，並且藉助一種與正常消息不同的特殊消息作為標記，英文稱為marker。這3個階段並沒有直接體現在論文中，而是出自 普林斯頓大學相關課程的PPT ，但演算法唯迅實際流程則是嚴格一致的。下面敘述3個階段的流程。

假設進程p i 發起快照：

對於任意一個進程p j （包含發起快照的那個進程），考慮它的所有入邊鏈路c kj 。當在c kj 上收到了marker消息時，有兩種情況。

若所有進程都成功地：

則快照成功，演算法流程結束。然後就可以將所有這些狀態傳輸到一個穩定的分布式存儲中心，全局快照就產生了。

全局快照的難點在於，因為系統不能停止，每個進程向下游發送的消息是源源不斷的，所以必須得有個東西來劃分「當前的消息」與「將來的消息」，讓它們不會混淆，而marker消息就是這個界限。對進程p j 的入邊鏈路c kj 而言，如果收到的消息序列是[a, b, c, marker, d, e, f]，那麼就說明a/b/c三條消息屬於當前快照，而d/e/f三條消息屬於下一個快照。

另外，因為每個進程都記錄自己收到的消息，所以進程最終都能持有入邊鏈路的狀態。為什麼要用接收進程來記錄？用兩句大白話來解釋：

如果不這樣設計，而採用簡單的單令牌系統的話，就會有問題。仍然借用論文中給出的一個例子：

進程p和q以令牌（token）的傳送來標定狀態，s1表示州汪持有令牌，s0表示未持有令牌。假設在「token in C」全局狀態下保存快照，而q的時間戳比p早，那麼就會造成兩個進程都處於s0狀態，而q認為令牌不在鏈路C中，p也認為令牌不在鏈路C'中，因此快照里令牌就會丟失，造成不一致。

下面的圖示出有兩個進程的分布式系統根據Chandy-Lamport演算法生成快照的過程，其中藍色的部分表示狀態已經被保存，並且進程P 1 發起快照。

天氣是真的涼了哈。

晚安晚安。

❷ 【Flink 精選】闡述 Flink 的容錯機制，剖析 Checkpoint 實現流程

Flink 容錯機制主要是 狀態的保存和恢復，涉及 state backends 狀態後端、checkpoint 和 savepoint，還有 Job 和 Task 的錯誤恢復 。

Flink 狀態後端是指 保存 Checkpoint 數據的容器 ，其分類有 MemoryStateBackend、FsStateBackend、RocksDBStateBackend ，狀態的分類有 operator state 和 keyed state 。

Flink 狀態保存和恢復主要依靠 Checkpoint 機制和 Savepoint 機制，兩者的區別如下表所示。

快照的概念來源於相片，指照相館的一種沖洗過程短搜隱的照片。在計算機領域， 快照是數據存儲的某一時刻的狀態記錄 。 Flink Snapshot 快照是指作業狀態的全局一致記錄 。一個完整的快照是包括 source 運算元的狀態（例如，消費 kafka partition 的 offset）、狀態運算元的緩存數據和 sink 運算元的狀態（批量緩存數據、事務數據等）。

Checkpoint 檢查點可以自動產生快照，用於Flink 故障恢復 。Checkpoint 具有分布式、非同步、增量的特點。

Savepoint 保存點是用戶手動觸發的，保存全量的作業狀態數據 。一般使用場景是作業的升級、作業的並發度縮放、遷移集群等。

Flink 是採用輕量級的分布式非同步快照，其實現是採用柵欄 barrier 作為 checkpoint 的傳遞信號，與業務數據一樣無差別地傳遞下去 ，目的是使得數據流被切分成微批，進行 checkpoint 保存為 snapshot。當 barrier 經過流圖節點的時候，Flink 進行 checkpoint 保存狀態數據。
如下圖所示，checkpoint n 包含每個運算元的狀態，該狀態是指checkpoint n 之前的全部事件，而不包含它之後戚譽的所有事件。

針對用戶作業出現故障而導致結果丟失或者重復的問題，Flink 提供3種語義：
① At-Least-Once 最少一次 ：不會丟失數據，但可能會有重復結果。
② Exactly-Once 精確一次 ：checkpoint barrier 對齊機制可以保障精確一次。

① FailureRateRestartStrategy ：允許在指定時間間隔內的最大失敗次數，同時可以設置重啟延時時間。
② FixedDelayRestartStrategy ：允許指定的失敗次數，同時可以設置重啟延時時間。
③ NoRestartStrategy ：不需要重啟，即 Job 直接失敗。
④ ThrowingRestartStrategy ：不需要重啟，直接拋異常。
Job Restart 策略可以通過 env 設置。

上述策略的父類介面是RestartStrategy，其關鍵是restart（重啟操作）。

① RestartAllStrategy ：重啟全部 task，默認策略。
② RestartIndivialStrategy ：恢復單個 task。如果該 task 沒有source，可能導致數據丟失。
③ NoOpFailoverStrategy ：不恢復 task。
上述策略的父類介面是FailoverStrategy，其關鍵是Factory的create（創建 strategy）、onTaskFailure（處理錯誤）。

如何高漏段產生可靠的全局一致性快照是分布式系統的難點，其傳統方案是使用的全局時鍾，但存在單點故障、數據不一致等可靠性問題 。為了解決該問題， Chandy-Lamport 演算法採用 marker 的傳播來代替全局時鍾 。

① 進程 Pi 記錄自己的進程狀態，同時生產一個標識信息 marker（與正常 message 不同），通過 ouput channel 發送給系統裡面的其他進程。
② 進程 Pi 開始記錄所有 input channel 接收到的 message

進程 Pj 從 input channel Ckj 接收到 marker。如果 Pj 還沒有記錄自己的進程狀態，則 Pj 記錄自己的進程狀態，向 output channel 發送 marker；否則 Pj 正在記錄自己的進程狀態（該 marker 之前的 message）。

所有的進程都收到 marker 信息並且記錄下自己的狀態和 channel 的狀態（包含的 message）。

Flink 的分布式非同步快照實現了Chandy Lamport 演算法，其核心思想是 在 source 插入 barrier 代替 Chandy-Lamport 演算法中的 marker，通過控制 barrier 的同步來實現 snapshot 的備份和 Exactly-Once 語義 。

Checkpoint Coordinator 向所有 source 節點 trigger Checkpoint。

source task向下游廣播barrier。

當source task備份完自己的狀態後，會將備份數據的地址（state handle）通知 Checkpoint Coordinator。

map和sink task收集齊上游source的barrier n，執行本地快照。下面例子是RocksDB增量Checkpoint 的流程：首先RocksDB會全量保存到磁碟上（紅色大三角表示），然後Flink會從中選擇沒有上傳的文件進行持久化備份（紫色小三角）。

map和sink task在完成Checkpoint 之後，將狀態地址state handle返回通知 Coordinator。

當Checkpoint Coordinator收到全部task的state handle，就確定該Checkpoint已完成，並向持久化存儲中備份一個Checkpoint Meta（元數據，包括該checkpoint狀態數據的備份地址）。

❸ FLink Checkpoint 介紹

這一篇主要整理下Lightweight Asynchronous Snapshots for Distributed Dataflows 知識點。

演算法的前提:

1.狀態只有進程本地狀態，並沒有管道狀態(輸入檔鎮管道buffer數據，不作為狀態一分部行喚粗)
2.由同類型進程(source節點)周期出發marker消息。

更接近Candy-Lamport的實現

這里Operator的輸入分為兩種

有環ABS比起無環ABS,更像是Candy-Lamport的最完整的實現。

非對齊checkpoint也是最接近Candy-Lamport的實現，狀態是進程狀態和管道消息。

flink的快照機制其實是參考Candy-Lamport演算法實現的鏈滑，除了在source周期注入marker消息以外，最大的區別就是狀態的組成上。
無法環ABS只有本地快照狀態，有環ABS狀態是本地快照狀態 + 環路輸入消息
非對齊checkpoint則是本地快照 + 輸入消息 + 輸出消息

❹ 驗證lamport's algorithm演算法的正確性，即該演算法是否能保證

演算法（Algorithm）是解題的步驟，可以把演算法定義成解一確定類問題的任意一種特殊的方法。在計算機科學中，演算法要用計算機演算法語言描述，演算法代表用計算機解一類問題的精確、有效的方法。演算法+數據結構=程序，求解一個給定的可計算或可解的問題，不同的人可以編寫出不同的程序，來解決同一個問題，這里存在兩個問題：一是與計算方法密切相關的演算法問題；二是程序設計的技術問題。演算法和程序之間存在密切的關系。

❺ 常見的共識演算法介紹

在非同步系統中，需要主機之間進行狀態復制，以保證每個主機達成一致的狀態共識。而在非同步系統中，主機之間可能出現故障，因此需要在默認不可靠的非同步網路中定義容錯協議，以確保各個主機達到安全可靠的狀態共識。

共識演算法其實就是一組規則，設置一組條件，篩選出具有代表性的節點。在區塊鏈系統中，存在很多這樣的篩選方案，如在公有鏈中的POW、Pos、DPOS等，而在不需要貨幣體系的許可鏈或私有鏈中，絕對信任的節點、高效的需求是公有鏈共識演算法不能提供的，對於這樣的區塊鏈，傳統的一致性共識演算法成為首選，如PBFT、PAXOS、RAFT等。

目錄

一、BFT（拜占庭容錯技術）

二、PBFT（實用拜占庭容錯演算法）

三、PAXOS

四、Raft

五、POW（工作量證明）

六、POS（權益證明）

七、DPOS（委任權益證明）

八、Ripple

拜占庭弄錯技術是一類分布式計算領域的容錯技術。拜占庭假設是由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊的原因，計算機和網路出現不可預測的行為。拜占庭容錯用來處理這種異常行為，並滿足所要解決問題的規范。

拜占庭容錯系統是一個擁有n台節點的系統，整個系統對於每一個請求，滿足以下條件：

1）所有非拜占庭節點使用相同的輸入信息，產生同樣的結果；

2）如果輸入的信息正確，那麼所有非拜占庭節點必須接收這個信息，並計算相應的結果。

拜占庭系統普遍採用的假設條件包括：

1）拜占庭節點的行為可以是任意的，拜占庭節點之間可以共謀；

2）節點之間的錯誤是不相關的；

3）節點之間通過非同步網路連接，網路中的消息可能丟失、亂序並延時到達，但大部分協議假設消息在有限的時間里能傳達到目的地；

4）伺服器之間傳遞的信息，第三方可以嗅探到，但是不能篡改、偽造信息的內容和驗證信息的完整性。

拜占庭容錯由於其理論上的可行性而缺乏實用性，另外還需要額外的時鍾同步機制支持，演算法的復雜度也是隨節點的增加而指數級增加。

實用拜占庭容錯降低了拜占庭協議的運行復雜度，從指數級別降低到多項式級別。

PBFT是一種狀態機副本復制演算法，即服務作為狀態機進行建模，狀態機在分布式系統的不同節點進行副本復制。PBFT要求共同維護一個狀態。需要運行三類基本協議，包括一致性協議、檢查點協議和視圖更換協議。

一致性協議。一致性協議至少包含若干個階段：請求（request）、序號分配（pre-prepare）和響應（reply），可能包含相互交互（prepare），序號確認（commit）等階段。

PBFT通信模式中，每個客戶端的請求需要經過5個階段。由於客戶端不能從伺服器端獲得任何伺服器運行狀態的信息，PBFT中主節點是否發生錯誤只能由伺服器監測。如果伺服器在一段時間內都不能完成客戶端的請求，則會觸發視圖更換協議。

整個協議的基本過程如下：

1）客戶端發送請求，激活主節點的服務操作。

2）當主節點接收請求後，啟動三階段的協議以向各從節點廣播請求。

［2.1］序號分配階段，主節點給請求賦值一個序列號n，廣播序號分配消息和客戶端的請求消息m，並將構造PRE-PREPARE消息給各從節點；

［2.2］交互階段，從節點接收PRE-PREPARE消息，向其他服務節點廣播PREPARE消息；

［2.3］序號確認階段，各節點對視圖內的請求和次序進行驗證後，廣播COMMIT消息，執行收到的客戶端的請求並給客戶端以響應。

3）客戶端等待來自不同節點的響應，若有m+1個響應相同，則該響應即為運算的結果。

PBFT一般適合有對強一致性有要求的私有鏈和聯盟鏈，例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。

在有些分布式場景下，其假設條件不需要考慮拜占庭故障，而只是處理一般的死機故障。在這種情況下，採用Paxos等協議會更加高效。。PAXOS是一種基於消息傳遞且具有高度容錯特性的一致性演算法。

PAXOS中有三類角色Proposer、Acceptor及Learner，主要交互過程在Proposer和Acceptor之間。演算法流程分為兩個階段：

phase 1

a) proposer向網路內超過半數的acceptor發送prepare消息

b) acceptor正常情況下回復promise消息

phase 2

a) 在有足夠多acceptor回復promise消息時，proposer發送accept消息

b) 正常情況下acceptor回復accepted消息

流程圖如圖所示：

PAXOS協議用於微信PaxosStore中，每分鍾調用Paxos協議過程數十億次量級。

Paxos是Lamport設計的保持分布式系統一致性的協議。但由於Paxos非常復雜，比較難以理解，因此後來出現了各種不同的實現和變種。Raft是由Stanford提出的一種更易理解的一致性演算法，意在取代目前廣為使用的Paxos演算法。

Raft最初是一個用於管理復制日誌的共識演算法，它是在非拜占庭故障下達成共識的強一致協議。Raft實現共識過程如下：首先選舉一個leader，leader從客戶端接收記賬請求、完成記賬操作、生成區塊，並復制到其他記賬節點。leader有完全的管理記賬權利，例如，leader能夠決定是否接受新的交易記錄項而無需考慮其他的記賬節點，leader可能失效或與其他節點失去聯系，這時，重新選出新的leader。

在Raft中，每個節點會處於以下三種狀態中的一種：

（1）follower：所有結點都以follower的狀態開始。如果沒收到leader消息則會變成candidate狀態；

（2）candidate：會向其他結點「拉選票」，如果得到大部分的票則成為leader。這個過程就叫做Leader選舉(Leader Election)；

（3）leader：所有對系統的修改都會先經過leader。每個修改都會寫一條日誌(log entry)。leader收到修改請求後的過程如下：此過程叫做日誌復制（Log Replication）

1）復制日誌到所有follower結點

2）大部分結點響應時才提交日誌

3）通知所有follower結點日誌已提交

4）所有follower也提交日誌

5）現在整個系統處於一致的狀態

Raft階段主要分為兩個，首先是leader選舉過程，然後在選舉出來的leader基礎上進行正常操作，比如日誌復制、記賬等。

（1）leader選舉

當follower在選舉時間內未收到leader的消息，則轉換為candidate狀態。在Raft系統中：

1）任何一個伺服器都可以成為候選者candidate，只要它向其他伺服器follower發出選舉自己的請求。

2）如果其他伺服器同意了，發出OK。如果在這個過程中，有一個follower宕機，沒有收到請求選舉的要求，此時候選者可以自己選自己，只要達到N/2+1的大多數票，候選人還是可以成為leader的。

3）這樣這個候選者就成為了leader領導人，它可以向選民也就是follower發出指令，比如進行記賬。

4）以後通過心跳消息進行記賬的通知。

5）一旦這個leader崩潰了，那麼follower中有一個成為候選者，並發出邀票選舉。

6）follower同意後，其成為leader，繼續承擔記賬等指導工作。

（2）日誌復制

記賬步驟如下所示：

1）假設leader已經選出，這時客戶端發出增加一個日誌的要求；

2）leader要求follower遵從他的指令，將這個新的日誌內容追加到各自日誌中；

3）大多數follower伺服器將交易記錄寫入賬本後，確認追加成功，發出確認成功信息；

4）在下一個心跳消息中，leader會通知所有follower更新確認的項目。

對於每個新的交易記錄，重復上述過程。

在這一過程中，若發生網路通信故障，使得leader不能訪問大多數follower了，那麼leader只能正常更新它能訪問的那些follower伺服器。而大多數的伺服器follower因為沒有了leader，他們將重新選舉一個候選者作為leader，然後這個leader作為代表與外界打交道，如果外界要求其添加新的交易記錄，這個新的leader就按上述步驟通知大多數follower。當網路通信恢復，原先的leader就變成follower，在失聯階段，這個老leader的任何更新都不能算確認，必須全部回滾，接收新的leader的新的更新。

在去中心賬本系統中，每個加入這個系統的節點都要保存一份完整的賬本，但每個節點卻不能同時記賬，因為節點處於不同的環境，接收不同的信息，如果同時記賬，必然導致賬本的不一致。因此通過同時來決定那個節點擁有記賬權。

在比特幣系統中，大約每10分鍾進行一輪算力競賽，競賽的勝利者，就獲得一次記賬的權力，並向其他節點同步新增賬本信息。

PoW系統的主要特徵是計算的不對稱性。工作端要做一定難度的工作才能得出一個結果，而驗證方卻很容易通過結果來檢查工作端是不是做了相應的工作。該工作量的要求是，在某個字元串後面連接一個稱為nonce的整數值串，對連接後的字元串進行SHA256哈希運算，如果得到的哈希結果（以十六進制的形式表示）是以若干個0開頭的，則驗證通過。

比特幣網路中任何一個節點，如果想生成一個新的區塊並寫入區塊鏈，必須解出比特幣網路出的PoW問題。關鍵的3個要素是 工作量證明函數、區塊及難度值 。工作量證明函數是這道題的計算方法，區塊決定了這道題的輸入數據，難度值決定了這道題所需要的計算量。

（1）工作量證明函數就是<u style="box-sizing: border-box;"> SHA256 </u>

比特幣的區塊由區塊頭及該區塊所包含的交易列表組成。擁有80位元組固定長度的區塊頭，就是用於比特幣工作量證明的輸入字元串。

（2）難度的調整是在每個完整節點中獨立自動發生的。每2016個區塊，所有節點都會按統一的公式自動調整難度。如果區塊產生的速率比10分鍾快則增加難度，比10分鍾慢則降低難度。

公式可以總結為：新難度值=舊難度值×（過去2016個區塊花費時長/20160分鍾）

工作量證明需要有一個目標值。比特幣工作量證明的目標值（Target）的計算公式：目標值=最大目標值/難度值

其中最大目標值為一個恆定值：

目標值的大小與難度值成反比。比特幣工作量證明的達成就是礦工計算出來的 區塊哈希值必須小於目標值 。

（3）PoW能否解決拜占庭將軍問題

比特幣的PoW共識演算法是一種概率性的拜占庭協議（Probabilistic BA）

當不誠實的算力小於網路總算力的50%時，同時挖礦難度比較高（在大約10分鍾出一個區塊情況下）比特幣網路達到一致性的概念會隨確認區塊的數目增多而呈指數型增加。但當不誠實算力具一定規模，甚至不用接近50%的時候，比特幣的共識演算法並不能保證正確性，也就是，不能保證大多數的區塊由誠實節點來提供。

比特幣的共識演算法不適合於私有鏈和聯盟鏈。其原因首先是它是一個最終一致性共識演算法，不是一個強一致性共識演算法。第二個原因是其共識效率低。

擴展知識： 一致性

嚴格一致性，是在系統不發生任何故障，而且所有節點之間的通信無需任何時間這種理想的條件下，才能達到。這個時候整個系統就等價於一台機器了。在現實中，是不可能達到的。

強一致性，當分布式系統中更新操作完成之後，任何多個進程或線程，訪問系統都會獲得最新的值。

弱一致性，是指系統並不保證後續進程或線程的訪問都會返回最新的更新的值。系統在數據成功寫入之後，不承諾立即可以讀到最新寫入的值，也不會具體承諾多久讀到。但是會盡可能保證在某個時間級別（秒級）之後。可以讓數據達到一致性狀態。

最終一致性是弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。也就是說，如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。

在股權證明PoS模式下，有一個名詞叫幣齡，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000，這個時候，如果你發現了一個PoS區塊，你的幣齡就會被清空為0。你每被清空365幣齡，你將會從區塊中獲得0.05個幣的利息(假定利息可理解為年利率5%)，那麼在這個案例中，利息 = 3000 * 5% / 365 = 0.41個幣，這下就很有意思了，持幣有利息。

點點幣（Peercoin）是首先採用權益證明的貨幣。，點點幣的權益證明機制結合了隨機化與幣齡的概念，未使用至少30天的幣可以參與競爭下一區塊，越久和越大的幣集有更大的可能去簽名下一區塊。一旦幣的權益被用於簽名一個區塊，則幣齡將清為零，這樣必須等待至少30日才能簽署另一區塊。

PoS機制雖然考慮到了PoW的不足，但依據權益結余來選擇，會導致首富賬戶的權力更大，有可能支配記賬權。股份授權證明機制（Delegated Proof of Stake，DPoS）的出現正是基於解決PoW機制和PoS機制的這類不足。

比特股（Bitshare）是一類採用DPoS機制的密碼貨幣。它的原理是，讓每一個持有比特股的人進行投票，由此產生101位代表 , 我們可以將其理解為101個超級節點或者礦池，而這101個超級節點彼此的權利是完全相等的。如果代表不能履行他們的職責（當輪到他們時，沒能生成區塊），他們會被除名，網路會選出新的超級節點來取代他們。

比特股引入了見證人這個概念，見證人可以生成區塊，每一個持有比特股的人都可以投票選舉見證人。得到總同意票數中的前N個（N通常定義為101）候選者可以當選為見證人，當選見證人的個數（N）需滿足：至少一半的參與投票者相信N已經充分地去中心化。

見證人的候選名單每個維護周期（1天）更新一次。見證人然後隨機排列，每個見證人按序有2秒的許可權時間生成區塊，若見證人在給定的時間片不能生成區塊，區塊生成許可權交給下一個時間片對應的見證人。

比特股還設計了另外一類競選，代表競選。選出的代表擁有提出改變網路參數的特權，包括交易費用、區塊大小、見證人費用和區塊區間。若大多數代表同意所提出的改變，持股人有兩周的審查期，這期間可以罷免代表並廢止所提出的改變。這一設計確保代表技術上沒有直接修改參數的權利以及所有的網路參數的改變最終需得到持股人的同意。

Ripple（瑞波）是一種基於互聯網的開源支付協議，在Ripple的網路中，交易由客戶端（應用）發起，經過追蹤節點（tracking node）或驗證節點（validating node）把交易廣播到整個網路中。

追蹤節點的主要功能是分發交易信息以及響應客戶端的賬本請求。驗證節點除包含追蹤節點的所有功能外，還能夠通過共識協議，在賬本中增加新的賬本實例數據。

Ripple的共識達成發生在驗證節點之間，每個驗證節點都預先配置了一份可信任節點名單，稱為UNL（Unique Node List）。在名單上的節點可對交易達成進行投票。每隔幾秒，Ripple網路將進行如下共識過程：

1）每個驗證節點會不斷收到從網路發送過來的交易，通過與本地賬本數據驗證後，不合法的交易直接丟棄，合法的交易將匯總成交易候選集（candidate set）。交易候選集裡面還包括之前共識過程無法確認而遺留下來的交易。

2）每個驗證節點把自己的交易候選集作為提案發送給其他驗證節點。

3）驗證節點在收到其他節點發來的提案後，如果不是來自UNL上的節點，則忽略該提案；如果是來自UNL上的節點，就會對比提案中的交易和本地的交易候選集，如果有相同的交易，該交易就獲得一票。在一定時間內，當交易獲得超過50%的票數時，則該交易進入下一輪。沒有超過50%的交易，將留待下一次共識過程去確認。

4）驗證節點把超過50%票數的交易作為提案發給其他節點，同時提高所需票數的閾值到60%，重復步驟3）、步驟4），直到閾值達到80%。

5）驗證節點把經過80%UNL節點確認的交易正式寫入本地的賬本數據中，稱為最後關閉賬本（Last Closed Ledger），即賬本最後（最新）的狀態。

在Ripple的共識演算法中，參與投票節點的身份是事先知道的。該共識演算法只適合於許可權鏈（Permissioned chain）的場景。Ripple共識演算法的拜占庭容錯（BFT）能力為（n-1）/5，即可以容忍整個網路中20%的節點出現拜占庭錯誤而不影響正確的共識。

在區塊鏈網路中，由於應用場景的不同，所設計的目標各異，不同的區塊鏈系統採用了不同的共識演算法。一般來說，在私有鏈和聯盟鏈情況下，對一致性、正確性有很強的要求。一般來說要採用強一致性的共識演算法。而在公有鏈情況下，對一致性和正確性通常沒法做到百分之百，通常採用最終一致性（Eventual Consistency）的共識演算法。

共識演算法的選擇與應用場景高度相關，可信環境使用paxos 或者raft，帶許可的聯盟可使用pbft ，非許可鏈可以是pow，pos，ripple共識等，根據對手方信任度分級，自由選擇共識機制。

❻ 麵包店演算法的優缺點

優點：進程之間並行，有界共享寄存器。缺點：多進程讀/寫原子操作寄存器；飢餓問題，無容錯性（沒有等待資源釋放）。lamport演算法又稱為麵包店演算法，它解決了多個線程並發訪問一個共享的單用戶資源的互斥問題的演算法。優點：進程之間並行，有界共享寄存器。缺點：多進程姿寬讀/寫原子操作寄存器；飢餓問題，無容錯性（沒有等滑冊碰待資源釋放）。麵包信談店演算法借鑒生活中取號排隊的思想，取得的號不為0，則表示想要進去，按號碼從小到大授予訪問許可權。

❼ paxos演算法是什麼

Paxos演算法是萊斯利·蘭伯特（Leslie Lamport，就是LaTeX中的＂La"，此人現在在微軟研究院）於1990年提出的一種基於消息傳遞的一致性演算法。這個演算法被認為是類似演算法中最有效的。

蘭伯特提出的Paxos演算法包含2個部分：

一個是Basic Paxos演算法，描述的是多節點之間如何就某個值（提案Value）達成共識；

另一個是Multi-Paxos思想，描述的是執行多個Basic Paxos實例，就一系列值達成共識

可因為蘭伯特提到的Multi-Paxos思想，缺少代碼實現的必要細節（比如怎麼選舉領導者），所以在理解上比較難。Basic Paxos是Multi-Paxos思想的核心。

(7)lamport演算法擴展閱讀

背景

Paxos演算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點執行相同的操作序列，那麼他們最後能得到一個一致的狀態。

為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。

一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。因此從20世紀80年代起對於一致性演算法的研究就沒有停止過。節點通信存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。

❽ 分布式存儲中，怎樣使用paxos演算法保證數據的一致性

在分布式系統中，我們經常遇到多數據副本保持一致的問題，在我們所能找到的資料中該問題講的很籠統，模模糊糊的，把多個問題或分類糅合在一起，難以理解。在思考和翻閱資料後，通俗地把一致性的問題可分解為2個問題：
1、任何一次修改保證數據一致性。
2、多次數據修改的一致性。
在弱一致性的演算法，不要求每次修改的內容在修改後多副本的內容是一致的，對問題1的解決比較寬松，更多解決問題2，該類演算法追求每次修改的高度並發性，減少多副本之間修改的關聯性，以獲得更好的並發性能。例如最終一致性，無所謂每次用戶修改後的多副本的一致性及格過，只要求在單調的時間方向上，數據最終保持一致，如此獲得了修改極大的並發性能。
在強一致性的演算法中，強調單次修改後結果的一致，需要保證了對問題1和問題2要求的實現，犧牲了並發性能。本文是討論對解決問題1實現演算法，這些演算法往往在強一致性要求的應用中使用。
解決問題1的方法，通常有兩階段提交演算法、採用分布式鎖服務和採用樂觀鎖原理實現的同步方式,下面分別介紹這幾種演算法的實現原理。

兩階段提交演算法

在兩階段提交協議中，系統一般包含兩類機器（或節點）：一類為協調者（coordinator），通常一個系統中只有一個；另一類為事務參與者（participants，cohorts或workers），一般包含多個，在數據存儲系統中可以理解為數據副本的個數。兩階段提交協議由兩個階段組成，在正常的執行下，這兩個階段的執行過程如下所述：
階段1：請求階段（commit-request phase，或稱表決階段，voting phase）。
在請求階段，協調者將通知事務參與者准備提交或取消事務，然後進入表決過程。在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或取消（本地作業執行故障）。
階段2：提交階段（commit phase）。
在該階段，協調者將基於第一個階段的投票結果進行決策：提交或取消。當且僅當所有的參與者同意提交事務協調者才通知所有的參與者提交事務，否則協調者將通知所有的參與者取消事務。參與者在接收到協調者發來的消息後將執行響應的操作。
舉個例子：A組織B、C和D三個人去爬長城：如果所有人都同意去爬長城，那麼活動將舉行；如果有一人不同意去爬長城，那麼活動將取消。用2PC演算法解決該問題的過程如下：
首先A將成為該活動的協調者，B、C和D將成為該活動的參與者。
階段1：A發郵件給B、C和D，提出下周三去爬山，問是否同意。那麼此時A需要等待B、C和D的郵件。B、C和D分別查看自己的日程安排表。B、C發現自己在當日沒有活動安排，則發郵件告訴A它們同意下周三去爬長城。由於某種原因，D白天沒有查看郵件。那麼此時A、B和C均需要等待。到晚上的時候，D發現了A的郵件，然後查看日程安排，發現周三當天已經有別的安排，那麼D回復A說活動取消吧。
階段2：此時A收到了所有活動參與者的郵件，並且A發現D下周三不能去爬山。那麼A將發郵件通知B、C和D，下周三爬長城活動取消。此時B、C回復A「太可惜了」，D回復A「不好意思」。至此該事務終止。
兩階段提交演算法在分布式系統結合，可實現單用戶對文件（對象）多個副本的修改，多副本數據的同步。其結合的原理如下：
1、客戶端（協調者）向所有的數據副本的存儲主機（參與者）發送：修改具體的文件名、偏移量、數據和長度信息，請求修改數據，該消息是1階段的請求消息。
2、存儲主機接收到請求後，備份修改前的數據以備回滾，修改文件數據後，向客戶端回應修改成功的消息。 如果存儲主機由於某些原因（磁碟損壞、空間不足等）不能修改數據，回應修改失敗的消息。
3、客戶端接收發送出去的每一個消息回應，如果存儲主機全部回應都修改成功，向每存儲主機發送確認修改的提交消息；如果存在存儲主機回應修改失敗，或者超時未回應，客戶端向所有存儲主機發送取消修改的提交消息。該消息是2階段的提交消息。
4、存儲主機接收到客戶端的提交消息，如果是確認修改，則直接回應該提交OK消息；如果是取消修改，則將修改數據還原為修改前，然後回應取消修改OK的消息。
5、 客戶端接收全部存儲主機的回應，整個操作成功。
在該過程中可能存在通信失敗，例如網路中斷、主機宕機等諸多的原因，對於未在演算法中定義的其它異常，都認為是提交失敗，都需要回滾，這是該演算法基於確定的通信回復實現的，在參與者的確定回復（無論是回復失敗還是回復成功）之上執行邏輯處理，符合確定性的條件當然能夠獲得確定性的結果哲學原理。

分布式鎖服務

分布式鎖是對數據被外界修改持保守態度，在整個數據處理過程中將數據處於鎖定狀態，在用戶修改數據的同時，其它用戶不允許修改。
採用分布式鎖服務實現數據一致性，是在操作目標之前先獲取操作許可，然後再執行操作，如果其他用戶同時嘗試操作該目標將被阻止，直到前一個用戶釋放許可後，其他用戶才能夠操作目標。分析這個過程，如果只有一個用戶操作目標，沒有多個用戶並發沖突，也申請了操作許可，造成了由於申請操作許可所帶來的資源使用消耗，浪費網路通信和增加了延時。
採用分布式鎖實現多副本內容修改的一致性問題， 選擇控制內容顆粒度實現申請鎖服務。例如我們要保證一個文件的多個副本修改一致， 可以對整個文件修改設置一把鎖，修改時申請鎖，修改這個文件的多個副本，確保多個副本修改的一致，修改完成後釋放鎖；也可以對文件分段，或者是文件中的單個位元組設置鎖， 實現更細顆粒度的鎖操作，減少沖突。
常用的鎖實現演算法有Lamport bakery algorithm （俗稱麵包店演算法）， 還有Paxos演算法。下面對其原理做簡單概述。

Lamport麵包店演算法

是解決多個線程並發訪問一個共享的單用戶資源的互斥問題的演算法。 由Leslie Lamport（英語：Leslie Lamport）發明。
Lamport把這個並發控制演算法可以非常直觀地類比為顧客去麵包店采購。麵包店只能接待一位顧客的采購。已知有n位顧客要進入麵包店采購，安排他們按照次序在前台登記一個簽到號碼。該簽到號碼逐次加1。根據簽到號碼的由小到大的順序依次入店購貨。完成購買的顧客在前台把其簽到號碼歸0. 如果完成購買的顧客要再次進店購買，就必須重新排隊。
這個類比中的顧客就相當於線程，而入店購貨就是進入臨界區獨占訪問該共享資源。由於計算機實現的特點，存在兩個線程獲得相同的簽到號碼的情況，這是因為兩個線程幾乎同時申請排隊的簽到號碼，讀取已經發出去的簽到號碼情況，這兩個線程讀到的數據是完全一樣的，然後各自在讀到的數據上找到最大值，再加1作為自己的排隊簽到號碼。為此，該演算法規定如果兩個線程的排隊簽到號碼相等，則線程id號較小的具有優先權。
把該演算法原理與分布式系統相結合，即可實現分步鎖。

Paxos演算法

該演算法比較熱門，參見WIKI，http://zh.wikipedia.org/wiki/Paxos%E7%AE%97%E6%B3%95
Paxos演算法解決的問題是一個分布式系統如何就某個值(決議)達成一致。一個典型的場景是，在一個分布式資料庫系統中，如果各節點的初始狀態一致，每個節點都執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個「一致性演算法」以保證每個節點看到的指令一致。一個通用的一致性演算法可以應用在許多場景中，是分布式計算中的重要問題。節點通信存在兩種模型：共享內存(Shared memory)和消息傳遞(Messages passing)。Paxos演算法就是一種基於消息傳遞模型的一致性演算法。BigTable使用一個分布式數據鎖服務Chubby，而Chubby使用Paxos演算法來保證備份的一致性。

採用樂觀鎖原理實現的同步

我們舉個例子說明該演算法的實現原理。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用前面的分布式鎖服務機制，也就意味著整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對幾百上千個並發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。樂觀鎖，大多是基於數據版本（ Version）記錄機制實現。何謂數據版本？即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加一個 「version」 欄位來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。
對於上面修改用戶帳戶信息的例子而言，假設資料庫中帳戶信息表中有一個 version 欄位，當前值為 1 ；而當前帳戶余額欄位（ balance ）為 $100 。
操作員 A 此時將其讀出（version=1 ），並從其帳戶余額中扣除 $50（$100-$50 ）。
在操作員 A 操作的過程中，操作員B也讀入此用戶信息（ version=1 ），並從其帳戶余額中扣除 $20 （ $100-$20 ）。
操作員 A 完成了修改工作，將數據版本號加一（ version=2 ），連同帳戶扣除後余額（ balance=$50 ），提交至資料庫更新，此時由於提交數據版本大於資料庫記錄當前版本，數據被更新，資料庫記錄 version 更新為 2 。
操作員 B 完成了操作，也將版本號加一（ version=2 ）試圖向資料庫提交數據（ balance=$80 ），但此時比對資料庫記錄版本時發現，操作員 B 提交的數據版本號為 2 ，資料庫記錄當前版本也為 2 ，不滿足 「 提交版本必須大於記錄當前版本才能執行更新 「 的樂觀鎖策略，因此，操作員 B 的提交被駁回。這樣，就避免了操作員 B 用基於 version=1 的舊數據修改的結果覆蓋操作員A 的操作結果的可能。
樂觀鎖機制與分布式系統相結合上， 我整理了偽代碼如下：
obj 操作的目標
vlaue 修改的值
atom_update_ver 每個目標上的版本，每次修改該值遞增
set( obj, value)
{
//從每個節點上取出修改前的對象版本
get original_ver = obj.atom_update_ver from each node;
//將值賦到每個節點的obj目標
set obj = value from each node;
//條件修改每個節點的obj版本，目標版本加一
//比較和修改操作是原子操作
result = (set obj.atom_update_ver = original_ver + 1
where original_ver + 1 > obj.atom_update_ver
for each node);
if(result == ok)
return set_ok;
else
return set(obj, value);//不成功遞歸修改

該演算法未考慮節點下線、失效等問題，在後續我將分析採用樂觀鎖原理實現一致性演算法，解決問題2、節點失效、通信失敗等問題。