Practical Fast Replication
來自NSDI 2019《Exploiting Commutativity For Practical Fast Replication 》的 idea，主要工作是對資料多副本一致性複製協議latency的優化工作，覺得有點意思，在這裡分享給大家，* 壓壓驚* ，畢竟最近江湖腥風血雨，不太平。
1. Introduce
為了保證分散式系統資料的可靠性和可用性，通常資料會儲存多個副本，多個副本就必定有資料一致性的問題，而最關鍵就是如何實現副本資料的複製，當前最主流的解決方案就是（1）基於強Leader的資料一致性複製協議，例如raft或者multi-paxos，它們都是基於RSM的 Leader-Follower複製 模型，如下圖[2]：
一個request從client端到Leader，Leader再發送給Follower，等到大多數返回，就可以返回client端，網路上的延遲在 2RTT 。還有一些基於（2） 鏈式複製 ，例如window azure storage[3]的Stream Layer，則採用如下圖的鏈式複製模式，client端的資料先到Primary，然後在發給secondary 1，secondary 1落盤同時再發送給secondary 2，然後secondary 2落盤返回secondary 1成功，secondary 1自己落盤成功且secondary 2返回成功，那麼就返回Primary，最後由Primary返回client，實際上這是一個帶有pipeline複製優化的鏈式複製，其網路的 延遲 >2rtt ， <3rtt 。（更多的討論和總結可以參考文獻[2]）
一個是 2rtt ，一個是2個多 rtt ，那麼有沒有什麼複製模型，能 1rtt 搞定，並且能夠滿足可靠性，可用性和一致性呢？今天就給大家分享的NSDI 2019《Exploiting Commutativity For Practical Fast Replication 》在這方面的探索，這篇文章來自斯塔福大學RAMCloud group andPlatform Lab，他們提出了一種 Consistent Unordered Replication Protocol (CURP) 的方案，可以實現在大多數的請求能夠在 1rtt 網路延遲中完成。
2. CURP Protocol
2.1. Idea
對於Consistent replication protocols最重要無非兩點:
- Consistent Ordering: all replicas should appear to execute operations in the same order
- Durability: once completed, an operation must survive crashes
傳統的一致性複製協議（例如raft/multi-paxos等）都會滿足以上兩點，而往往滿足以上兩點，意味著效能會遇到一些問題，所以前有multi-paxos基於類似pipeline複製的亂序commit，但是並不能亂序apply，所以後來又有了Parallel Raft[4]通過讓raft協議感知具體應用而實現亂序Apply，其實都是想在第1點上做些突破。因為永續性並沒有任何妥協的餘地，而亂序可以在應用具體場景感知的情況下實現，CURP這次也不例外， 其 Exploiting Commutativity 讓Ordering可以延遲確定 ，所謂的 Commutativity 就是兩個Op request之間沒有依賴關係，例如操作不同的object，操作的不同key-value，那麼這兩個Op的順序自然可以 交換 ，也就是可以亂序，CURP就是利用這一點，在複製模型上做了一些設計，從而實現了 1rtt 的網路延遲。
2.2. Overview of CURP
如上圖所示，為CURP的整體結構，其主要由4部分組成：
- client：負責接收到一個op request，會發送給primary和witnesses，等到primary和witnesses都返回成功了，那麼op request就成功了
- primary：也就是副本的leader，primary收到client的request， 會立馬返回執行結果，然後非同步的複製給backups
- backups：其它副本，接收primary的資料複製
- witnesses：接收client的op request，如果此op和witness上已經儲存的所有Op都滿足
Commutativity特性，那麼就持久化之後返回成功，否則返回reject；一旦client收到reject，就會給primary傳送sync rpc，這個時候，primary會sync資料到backups，大多數backups返回之後，才會返回client端成功，如下圖：
通過上面的描述，不難發現，如果一個op request和witness上的所有資料都是沒有衝突可 Commutativity ，那麼client端返回成功response僅僅需要 1 rtt 。
2.3. Crash Recovery
下面就分析一下，CURP如何做Crash Recovery，如下圖，假設Leader掛了，那麼其恢復步驟如下：
- 選出新的Leader，從backup中恢復資料，顯然primary向backup複製資料是非同步的，僅僅從backup恢復資料是不夠的，所以需要進行第二步
- 從witness回放資料，也就是從witness上獲取所有的資料，然後回放
顯然witness上面的資料並沒有順序，但是沒有關係，因為我們之前存放在witness上面的資料就是沒有任何衝突可 Commutativity 。是不是很巧妙。
這裡實際上還需要解決一個問題，那就是 線性化語義 [5]:
linearizable semantics (each operation appears to execute instantaneously, exactly once, at some point between its invocation and its response)
也就是一個op request不能被重複執行，因為witness上replay的資料，可能在backups上面已經恢復過了，這個其實是實現 lineariazble 的一個共性問題，raft[5]論文和client互動的章節有描述，這裡不在贅述。
這裡實際上就是利用 Commutativity ，在滿足永續性的同時，實現了 Ordering defer 。
2.4. Consistent Reads
如上圖所示，因為Primary複製資料給Backups是非同步的，所以Primary上總是會有一些資料已經synced到了backups，一些unsynced到backups，那麼這個時候來了一個read，Primary該如何處理呢？
為了保證一致性， 如果op和unsynced的任何一個op有衝突不可 Commutativity ，那麼Primary必須等到此Op已經synced到backups之後，才能返回 ，因為如果Primary返回了unsynced的Op，那麼將有可能在Primary crash的時候出現不一致，例如，一個 write x=4 的op1 unsynced到backsup，來了一個 read x 的op2，如果op2直接返回 x=2 ，此時Leader掛了，那麼可能 write x=4 在backups和witness上面都沒有，從而返回 Not-yet-durable Data ，顯然這樣就正確了。
3. Summary
CURP充分利用 Commutativity 實現了 Order defer ，實現了一些場景的latency降低，也算是一種全新的思路。限於時間，沒有將論文中更多內容整理展示出來，例如，配置變更，從Follower read，witness gc等等，感興趣的可以詳細參考論文。
Notes
限於作者水平，難免有理解和描述上有疏漏或者錯誤的地方，歡迎共同交流；部分參考已經在正文和參考文獻中列表註明，但仍有可能有疏漏的地方，有任何侵權或者不明確的地方，歡迎指出，必定及時更正或者刪除；文章供於學習交流，轉載註明出處
參考文獻
[1]. Park S J, Ousterhout J. Exploiting Commutativity For Practical Fast Replication[C]//16th {USENIX} Symposium on Networked Systems Design and Implementation ({NSDI} 19). 2019: 47-64.
[2]. Replication Model. https:// github.com/brpc/braft/b lob/master/docs/cn/replication.md
[3]. Calder B, Wang J, Ogus A, et al. Windows Azure Storage: a highly available cloud storage service with strong consistency[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. ACM, 2011: 143-157.
[4]. Cao W, Liu Z, Wang P, et al. PolarFS: an ultra-low latency and failure resilient distributed file system for shared storage cloud database[J]. Proceedings of the VLDB Endowment, 2018, 11(12): 1849-1862.
[5]. Ongaro D, Ousterhout J. In search of an understandable consensus algorithm[C]//2014 {USENIX} Annual Technical Conference ({USENIX}{ATC} 14). 2014: 305-319.