本文整理自APMCon 2016中國應用效能管理大會 資料庫效能優化專場 京東資深架構師 張成遠 題為《深入理解Raft及在NewSQL中的使用》的演講，現場解讀Raft核心內容，剖析etcd Raft庫的設計實現，針對此類複雜分散式系統演算法的測試方法，並介紹業界主流NewSQL的詳細設計，Raft在其中發揮的重要作用，以及如何使用等。

張成遠：我是京東資深架構師張成遠，目前主要是做分散式資料庫相關的一些架構研發等工作。今天主要講一下Raft在NewSQL的使用，因為內容涉及到Raft和NewSQL，我會先講一下什麼是NewSQL，什麼是事務以及一致性等，還有NewSQL大概是怎麼做的，然後再講一下Raft是什麼以及Raft是怎麼樣工作的。

一、What is NewSQL

從SQL到NoSQL再到NewSQL，一路走來大概經歷過這樣一個發展過程，一開始最早的時候是SQL類產品，後來慢慢有了NoSQL的東西，最近這一兩年開始有NewSQL這個概念。SQL理論，也就是關係型資料庫理論大概是上世紀70年代左右就是已經提出來了，這個理論下產生了很多的產品，像MySQL、Oracle、PostgreSQL、SQL Server等很多很多。

後來隨著分散式系統的發展衍生了NoSQL這個概念，出現了很多的分散式儲存系統像Redis、mongoDB、cassandra等，這些NoSQL類的產品特點是不支援SQL，主要以KV形式儲存，在擴容方面非常容易，可以較為輕鬆的進行一些叢集的伸縮等操作。NoSQL出來以後一直喊著要把SQL顛覆，後來在實際生產環境中我們發現這兩者是一種長期並存的趨勢，每類產品都有一定的適用場景。

等到後來，大家可能希望出現一種東西可以結合SQL跟NoSQL的優點，既支援SQL支援事務又可以比較容易的進行叢集的伸縮擴容等操作，讓海量資料方面的處理可以更加的容易，所以就出現了NewSQL的概念。NewSQL這個概念之下，國內外都有一些優秀的開源的專案在做像TiDB、CockroachDB等，但目前開源領域可能還沒有在生產環境當中真正大規模使用的。如果要說真正落地使用的話可能當屬google的F1/spanner了，但他們家沒有開源只有論文流出。

二、What is transaction

然後，接下來講一下NewSQL最大的特點，就是支援SQL同時支援事務，支援SQL比較好理解，相當於可以用SQL的方式來增刪改查這個系統，至於支援事務那我們就要回到非常老的一個問題，到底什麼是事務？支援事務，那事務到底是什麼定義？事務有ACID屬性，也就是原子性、一致性、隔離性還有永續性。

原子性是指整個事務要麼成功，要麼失敗(跟沒有發生過一樣)，不要有任何的中間狀態。

一致性其實在一定程度上來說主要是資料庫層面的完整性，打個比方A的帳戶裡面100塊錢，B的帳戶裡面50塊錢，然後，A給B 25塊錢，首先是從A上減去25塊錢，然後將這25塊錢加到B上，最終都是75塊錢。不能出現A減25塊錢然後B的25塊錢沒有加上去，這樣全域性資料庫完整性就不一致了，這個屬性需要應用程式自己做更多的考慮，另外資料庫層面保證了原子性、隔離性以及永續性的時候，外加應用程式自身的邏輯是正常的，那這個一致性就是可以保證的。

什麼是隔離性呢，一般是指併發事務操作彼此之間不可見，簡單的說就是A做操作的時候不要讓B事務看到。

永續性，簡單的理解就是事務commit了以後要保證這個事務是一直不會丟失的。比如你把A減了100塊錢或者A加了100塊錢，這個事情如果告訴使用者已經成功了就是成功了，不能出現因為機器掛掉之類導致這種修改丟失。

還有一個概念也要提一下，這個也是一個比較老的概念，就是CAP。

很多時候會把CAP一致性和ACID的一致性混在一起，CAP一致性跟ACID的一致性其實是兩回事情。CAP的一致性是針對很多個節點，要求各個節點之間的資料是完全一致的，也就是要求實際儲存的資料是完全一致的一致性，也就是純粹的多副本方式。

CAP裡的A其實就是高可用，簡單的理解就是隨時去訪問都可以訪問到，CAP裡的P是說在發生一些網路異常狀況的時候是否可以容忍。在絕大多數的系統當中，理論上來說CAP是不能同時滿足的，但在實際生產環境中往往選擇弱化的P，也就是當發生網路異常時直接將一部分異常節點捨棄保證剩餘節點的服務都是正常的從而保證了整體的服務，所以從這個角度上來說CAP是可以全部滿足的，或者說滿足生產需求已經足夠。

上圖是我們在做分散式資料庫的時候一般的一些做法，很多的時候直接基於一些現有的SQL類產品，比如MySQL，外加一層資料庫中介軟體的方式比如引入Proxy的方式來解決這個分散式資料庫問題，SQL發過來以後由Proxy接收然後解析拆解，再把相應的SQL發到相應的SQL產品上，支援簡單的事務。為什麼叫做簡單的事務呢，因為如果只涉及到一個分片是可以的，但是多個就是支援不了的，確切的說是因為不能保證嚴格的分散式事務的語義，後面會詳細講一下。

三、NewSQL 

那麼NewSQL是怎麼樣的？NewSQL有很多種可能的實現方式，這裡列舉NewSQL其中的一種架構模式，如上圖，上層相容SQL協議的一個協調者，然後通過RPC之類的通訊方式和底層儲存通訊，儲存節點可能會選擇Rocksdb之類的K/V儲存系統。為什麼說上圖這個是一個協調者，但看到的效果看起來也像一個代理像一個Proxy？他的區別在於可以做很多的事情，可以對這個事務進行一些記錄，記錄到日誌裡面，還可以提供全域性的事務ID之類，保證同一個大事務裡的各個節點上的子事務ID可以和全域性事務ID是一樣，後面會詳細講一下。

一般來說，NewSQL要支援SQL同時有NoSQL的優點，這個從實現上面來說給使用者的感覺就是SQL產品，SQL過來以後協調者會把它拆成各種各樣的KV操作，丟到各個節點上去，相當於丟到多個分片上，但同一個分片上有很多個節點，這些節點之間要保證資料是一致的，這樣可以做到這個分片上萬一有節點掛了，還有另外的節點可以對外提供服務。

1、隔離性

那怎麼保證同一個分片內多個節點之間的資料是一致的呢？Raft就是用來保證各個節點是一致的。為什麼上圖Rocksdb這層要引入Range的概念呢？因為作為一個節點可能資料量會非常大，後期要支援擴容怎麼擴？如果這個節點不拆分是沒有辦法擴的，所以要引入Range這個邏輯概念。需要擴容的時候就可以把Range進行拆分成多個，每一個Rocksdb上面放很多的Range，然後把這些Range遷移到其他的Rocksdb上面去，相當於通過拆分加遷移方式同時達到擴容整個叢集容量的目的，每一個Range相當於一個分片裡的節點，多個Range通過Raft構成一個分片，同一個分片裡的Range的資料是一樣的。

現在我們再回過頭去講一下，為什麼基於現有的SQL類產品開發一個Proxy的方式其實是沒有辦法保證嚴格的分散式事務的，有一種場景很容易理解：假設以MySQL為例，如果一個事務裡有多條SQL，這些SQL如果涉及到不同的MySQL例項，可能會出現一個分片的MySQL上提交成功了，另一個分片的MySQL掛了，那就會出現事務只提交一半的情況，這種情況就保證不了原子性。

如果有一個分片的MySQL掛了，事務的原子性無法保證這種場景是比較好理解的，但是其實就算所有的分片上的MySQL都是正常的也是無法嚴格保證事務的，為什麼呢？因為前面講過ACID裡有一個隔離性屬性，併發事務之間要求是不可見的，而基於MySQL中介軟體的方式是保證不了隔離性的。

如上圖，假設有4個事務是同時發生的，對於理解就是併發過去的到Proxy節點的時候實際上肯定是有一個順序的，這個順序我們假設是T1、T2、T3、T4個順序，如果4個事務涉及到4個分片，4個事務同時落到四個片的MySQL上但實際上在每個MySQL上這四個事務的執行順序可能是不一樣的，每個MySQL上會有自己的一個執行序列，也就是這些事務在每個MySQL上會組成一個可序列化排程的序列，所謂可序列化排程就是併發的事務操作會按照一定的順序執行，執行以後的效果等價於這些事務按照某個順序序列執行的效果，那麼這個排程式列就是可序列化排程的，而這些等價的序列順序可能是一樣的也可能是不一樣的。比如這四個事務T1、T2、T3、T4在分片一上的執行順序可能是T1、T3、T2、T4，分片二上的執行順序卻是T4、T2、T1、T3，分片三的執行順序是T1、T2、T3、T4，而分片四上的執行順序是T1、T4、T2、T3。

在這種情況下，分片2上就會出現事務T1會看到T4和T2的修改，而在分片1、3和4上，事務T1事務是先執行的，所以並不會看到T4和T2的修改，這就相當於在全域性範圍內，事務T4和T2的部分修改被T1讀到了，而另一部分卻沒有被T1讀取到，出現了T1和T2及T4之間的隔離是有問題的，所以在全域性範圍內是無法保證嚴格事務之間的隔離性的。

再舉個例子如圖所示，假設變數a和b都是5，此時有事務T1和T2且全域性執行順序是T1和T2，假設每個分片上都是按照T1和T2的方式執行，結果最終結果a和b都是14，此時是符合事務的可序列化排程的。

但是可能出現一種情況，在分片1上的執行順序是T2、T1，分片2上的執行順序是T1、T2，此時分片1上a就變成了15，而分片2上就變成了14， 這就不符合可序列化的條件了，因為從全域性來說T1和T2是混在一起的，即不等價於T1T2的執行順序也不等價於T2T1的執行順序。怎麼解決這個問題呢，這時一般會採用引入一個全域性的事務ID，在實際執行的時候可能會採用時間戳的方式，具體細節這塊今天先不展開討論了。

2、原子性

前面講了隔離性問題，現在我們再講一下原子性，在保證分散式事務的時候要支援分散式事務語義，那ACID 4個屬性都要滿足，前面介紹了隔離性，那原子性這個怎麼解決呢？在實際實現的時候往往採用類似兩階段提交的方式，我這裡畫的是兩階段提交的理論上的定義，全域性會有一個協調者，事務要提交的時候協調者會傳送請求到各個參與節點，參與節點確認可以提交了就會回覆給協調者表示通過，如果參與節點表示這個事務因為一些原因不能提交就會給協調者反饋說這個事務需要回滾，那麼協調者就會根據這些反饋資訊來綜合決定事務是否需要提交。只有所有的參與節點都表示可以提交，協調者才會在自己先寫日誌提交這個事務，然後傳送commit命令到所有的參與節點，如果出現任何一個參與節點表示需要回滾，那麼協調者就會在先寫日誌表示abort這個事務，然後把abort資訊傳送給每個節點。圖上的每一個圈都是一個系統的狀態，是一個典型的狀態機，其中兩層圓圈表示的終止狀態，整個狀態機最終會到達終止狀態上，狀態機的東西在後面我也會再提一下。

3、永續性

講完NewSQL裡怎麼支援原子性和隔離性，我們再講一下永續性。同時也要提一下CAP裡的一致性，剛才已經說了CAP的一致性和ACID裡的一致性不是一個概念，CAP裡的一致性是解決多個節點副本之間資料一致性的問題，好比MySQL的主從資料完全一樣，那就符合CAP裡的一致性，從這個層面上來說CAP裡的一致性其實對應事務裡的永續性。

為什麼這麼說呢，大家想一個例子，還是以MySQL的主從為例來說明。主從主要可以解決高可用的問題也可以解決資料備份的問題，如果主從之間假設沒有資料的複製，那麼在主掛了或者出異常以後，從接替主開始對外服務相當於保證了CAP裡的A，但是之前所有已經提交的事務都丟失了，因為主從之間沒有進行資料複製，相當於丟失了ACID裡的永續性。

假設主從之間有資料複製但是有延後，那麼當發生主從切換的時候，依然會存在事務丟失的情況，因為可能會出現有幾個事務在主上已經提交了，但是還沒有複製到從上，此時主掛了從開始擔任主對外提供服務依然保證了CAP裡的A，但是依然會存在已經提交的事務丟失的情況。所以從這個角度來說CAP裡的多個節點之間的一致性本質上是對應ACID屬性裡的永續性，如果不追求事務的永續性，那也就不用關心各個節點之間的資料是否一致了。

既然已經明確了CAP裡的一致性本質上對應了永續性這個屬性，那接下來的問題就是這個一致性也就是ACID裡的永續性怎麼做呢，對MySQL來說可能有半同步的複製方式，但是半同步在實際使用當中，如果真的出現一些問題比如網路問題或者機器效能問題等最終可能會變成非同步複製，並不能保證嚴格的一致性。

所以在NewSQL中一般會考慮採用Raft來保證一致性。如上所示各個Node裡有很多的Range，各個Range之間通過Raft來保證彼此之間的一致性，多個Range組成的Raft組合相當於是一個分片，Raft保證了這些Range之間的一致性從而保證了事務在同一個節點的多副本上的永續性。

四、What is raft

在真正開始介紹Raft之前，我想先引入一個狀態機的介紹，因為前面的部分以及後面的部分都會涉及到狀態機，那什麼是狀態機呢，需要簡單介紹一下。

1、State machine

其實狀態機可以簡單的理解就是一個五元組，狀態機可以記錄為M={Q, ?,δ, q0, F}，其中Q是狀態集合；?是輸入符號，在實際工程中也可以理解為具體的事件；δ是轉移函式，表示在某個狀態下接收了某個符號會進入到什麼狀態；q0是整個狀態機的可能的起始狀態；F是整個狀態機的終止狀態，在實際表示的時候一般會用上層的圓圈表示，終止狀態的理解更恰當的說是指相對穩定的狀態，所以並不是說到了終止狀態以後整個狀態機就不工作了，比如圖上這個狀態機的效果就是接收了1*0+(0|1)*的字串。之所以在這裡提一下狀態機到底是一個什麼東西是因為前面的兩階段提交就是一個狀態機，後面的Raft也是到處都是狀態機。

現在接下去講一下什麼是Raft，Raft簡單的說就是相比傳統的Paxos演算法來說是一個更簡單且比較容易理解，在工程上也比較容易實現的一種一致性演算法，通過選舉leader以及日誌複製的方式完成工作，具體的實現會有一些措施來確保整個演算法是可以安全工作的，比如如何保證操作複製到多數節點才生效，再比如出現異常時少數節點上有的日誌在大多數節點上可能是沒有的這種情況，如何通過演算法將這些日誌清除掉。

上圖是Raft工作的示意圖，Client傳送請求到Leader上，consensus部分可以理解為Raft的主要工作部分，請求先傳送到consensus模組，consensus部分會把操作先記錄到本地日誌中，然後同時將這個操作複製到大多數其他節點上去，等確認大多數節點已經接收到了這個操作，然後會把這個操作apply到上層的狀態機，在實際實現的時候可以理解為把這個操作真正的應用到K/V儲存上去，比如Rocksdb。

2、Server State

一個Raft組合相當於有很多節點，裡面除了leader的角色還會有其他的角色，上圖是一個角色轉換圖，一個新加入的節點首先是一個follower的角色，如果follower加入的時候發現沒有leader就會變成Candidate的角色，發起選舉準備競選leader，如果這個candidate節點收到了大多數節點的投票，那麼它就可以順利的成為leader開始對外提供服務。但是如果此時沒有選舉成功且整組裡還是沒有leader，那麼這個candidate會繼續進行選舉。如果這個candidate發起選舉的時候發現已經有其他的節點成為了leader，那麼它就會回到follower角色，這是一個典型的一個狀態機，其中follower是起始狀態，而follower和leader可以理解為終止狀態，candidate是普通中間狀態，也就是每一個節點的穩定狀態最終一定會在停留在這兩個狀態中的一個，終止狀態不代表一旦進入就要永遠停留在這個狀態，確切的說應該理解為一種相對穩定的狀態。

3、Term & log index

在介紹日誌複製之前，需要介紹兩個概念，Term和Log index，Term相當於一個抽象的邏輯時間單位，每個Term裡只有一個leader，如果在這個Term裡沒有發生網路抖動或者leader出異常的情況也就是沒有發生新的選舉的情況，那麼這個Term一直保持不變，leader也一直保持不變。Log index是指每條操作命令在記錄到日誌的時候所在日誌的位置，可以將log理解為一個很大的陣列，log index就像是這個大陣列的下標，往Log裡每新增一條操作，log index就加1。在新增操作的時候要同時記錄該操作對應的index以及Term，所以會出現不同操作命令對應的Term是一樣的情況，比如圖上x=1這個操作Term是1，log index是1，y=1這個操作Term是2，log index是2，假如在此時發生了一次選舉，後面的操作的記錄情況可能出現如圖上所示的情況，x=7這個操作Term=2，log index是3，y=5這個操作Term=2, log index是4，x=2這個操作Term=2，log index是5，假設此時又發生了選舉，每次選舉的時候Term都會往上增加，此時Term變成了3但是因為一些原因這個Term內選舉沒有成功，當這次選舉失敗以後發現還沒有leader就繼續將Term增大到4繼續進行選舉，所以後面的y=3的操作記錄的時候對應的Term就是4，log index=6，緊接著之後y=6的操作Term=4，log index=7，後續其他操作的記錄方式跟這個類似。

4、Log replication

下面我們再以日誌複製的具體例子來分析一下日誌是怎麼在Raft的各個節點之間進行復制的。假設有3個節點，leader上有這些日誌，從圖上可以看到已經記錄了有12條操作，方框裡的數字是Term，從圖上可以看到這個系統已經發生過幾次選舉，但是這個leader後來重新選舉的時候又繼續成為了leader，方框上面的數字代表的是log index，可以看到log index是依次遞增的。這些所有的操作會被複制到所有的follower上，在leader這端相當於會維護一個資訊記錄每個follower都複製到哪裡了，比如這個圖上所示follower1已經複製到log index為6的位置了，而follow2已經複製到log index為9的位置了，因為leader自己已經到了log index為12的位置，那麼在全域性來說log index為9以及9之前的操作都已經複製到了大多數節點上，所以9這個位置及之前的操作都可以安全的apply到上層的狀態機，在實際實現的時候可以理解為可以把這個操作安全的應用到Rocksdb上，而9這個位置也就是commit index, commit index代表的是這個log index所在位置及以前的操作在全域性範圍內已經複製到了大多數節點上是不會丟失的，本質是滿足持久化條件的，所以可以安全的將這些操作真正的生效。

日誌複製裡還有兩條非常關鍵的特性，在同一個Raft組裡不同節點日誌上的操作如果log index和Term是一樣的，那麼對應的操作一定是一樣的；另一個是如果不同節點日誌上的某個位置擁有相同的log index和Term，那麼表示在這個位置之前的所有的操作都是一樣的。

具體講一下這個是怎麼做到的，這裡簡單舉個例子，上圖示意的是一個leader和其中一個follower的情況，假設這個follower是follower1，從圖上可以看出來Term為1的時候leader是leader，Term為2和3的時候，follower1成為了leader，不過從Term=4之後原來的leader又重新成為了leader，並且後來可能因為網路抖動等原因又發生了一次選舉，leader節點依然被選為了leader，所以會看到Term=5的時候leader這個角色保持不變。

此時出現了一種什麼情況呢，在follower1上我們可以看到Term=2和Term=3的時候對應的log index依次為4、5、6，而這三條操作在leader的日誌裡沒有。這是一種什麼樣的情況呢，有可能的一種情況是在Term=2和Term3的時候，follower1成為了leader，把這三個操作記錄到了自己的日誌中，但是還沒來得及複製到其他節點上結果因為網路抖動或者自身異常等一些原因，原來的leader重新發起選舉又成為了leader。這個時候原來leader對外正常提供了服務，且日誌裡記錄了Term=4及以後的操作，那這個follower1在接收leader日誌的時候有一部分日誌和leader的日誌就是不一樣的，這部分日誌我們之前也已經提過需要剔除掉的。

那怎麼剔除掉這部分日誌呢？在這個follower重新連上leader的時候，leader會把當前自身的<serverid, currentITerm, preLogTerm, preLogIndex> 資訊傳給follower1,  preLogTerm和preLogIndex分別是leader當前日誌裡的最後一條日誌的資訊，在這個圖中假設暫時沒有新的發生選舉，那麼此時leader傳給follower1的currentITerm、preLogTerm、preLogIndex分別是5,5,12。Follower1收到訊息以後會檢查自己日誌的資訊，一看自己當前的preLogTerm和preLogIndex分別是3和6，明顯是不對應的，所以follower會告知leader自己當前的lastLogIndex，也就是自己當前日誌的index位置，圖中的情況follower1告訴leader自己的last log index是7，此時leader會直接到自己log index為7的位置準備把資訊發給follower1，同時會把7位置之前的6位置的Term和log index資訊傳送給follower1，在leader上6位置的Term=4，而在follower1上6位置的Term=3，說明此時還是沒有匹配上，於是leader會繼續把該複製給follower1的日誌的起始位置繼續往日誌起始的方向挪動，一直到log index=3的時候Term=3剛好對應上，那說明此時leader和follower1在log index=3之前的位置記錄都是一樣的，可以從log index=4的位置開始將操作記錄一條一條的複製給follower1，從而做到即使因為一些極端的情況某些日誌不一致了也可以將沒有被複制到的大多數節點上的日誌是安全清除。

最後小結一下，今天主要是講了一下NewSQL怎麼支援分散式事務，根據事務ACID的屬性分析了一下，原子性主要是採用兩階段提交的方式來保證，一致性的話其實和傳統的資料庫的一致性一樣，主要是資料庫整體的完整性，隔離性的話可以考慮採用全域性時間戳這類的方式實現，永續性的話採用的Raft的方式也就是對應CAP裡的一致性。最後還講了Raft師怎麼工作的，最主要的就是兩部分，一個是leader選舉，一個是日誌複製。

關於APMCon：

2016中國應用效能管理大會（簡稱APMCon 2016）於8月18日至19日在北京新雲南皇冠假日酒店隆重召開。APMCon由聽雲、極客邦和InfoQ聯合主辦的作為國內APM領域最具影響力的技術大會，首次舉辦的APMCon以“驅動應用架構優化與創新”為主題，聚焦當前最為熱門的移動端、Web端和Server端的效能監控和管理技術，整個會議設定包含了：效能視覺化、服務端監控實踐、運維自動化、資料庫效能優化、APM雲服務架構和HTML5調優最佳實踐等話題，致力於推動APM在國內的成長與發展。