一、高可用架構介紹

1. 高可用架構是什么

首先來看一個問題，正常訪問網(wǎng)絡上一個服務的流程是，提交一個 request，然后服務進行一定的處理，返回給我們一個 success 的 response。但有時會因為網(wǎng)絡阻塞、資源不足，甚至黑客網(wǎng)絡攻擊或硬件毀損等原因，導致服務不能返回一個正確的 response，那么這時作為一個線上的業(yè)務，就是不可用的，可能會造成非常巨大的損失。

2. 高可用性代表系統(tǒng)的可用性程度，是進行系統(tǒng)設計時的準則之一

怎樣去衡量系統(tǒng)的可用性和不可用性呢？這就引出了高可用性的概念。高可用性代表系統(tǒng)的可用性程度，是進行系統(tǒng)設計的準則之一。高可用性，是系統(tǒng)的一個非常重要的能力，通常是通過提高系統(tǒng)的容錯能力來實現(xiàn)的?？捎眯缘囊粋€度量方式是根據(jù)系統(tǒng)損毀無法提供服務的時間和系統(tǒng)正常運行時間的比值來得到的。下圖右側(cè)表格展示了衡量一個系統(tǒng)可用性和不可用性的等級。

TuGraph-DB 對于可用性的要求，至少是 4 個 9 級別，也就是一年之內(nèi)宕機時間不能超過 53 分鐘。我們在開源之前服務的一個銀行用戶就已經(jīng)達到了一個極高可用的等級，也就是 5 個 9 的等級。

3. 常用高可用架構--主備復制

以上是高可用性的定義，為了達到高可用性，就需要去設計高可用架構。比較簡單的高可用架構，就是主備復制模式。主備復制模式有一個對外提供服務的主服務器，其它服務器作為其備機。主備復制模式最重要的特點是定期復制主機的數(shù)據(jù)給備機，比如一個小時、一天。當主機宕機之后，可以通過人工手段，也可以通過 NGINX 做請求轉(zhuǎn)發(fā)等自動的方式，讓備節(jié)點成為主節(jié)點。

這種模式非常簡單，只復制數(shù)據(jù)，也因為客戶只通過 URL 訪問對應的服務，因此是沒有感知的。但其弊端是需要人工干預，而更重要的問題是可能會丟失部分數(shù)據(jù)。不管以多快的頻率進行備份，一個小時，甚至十幾分鐘，都可能會丟失一部分數(shù)據(jù)，也就無法達成高可用的要求。這種模式比較適合于管理系統(tǒng)，比如學生管理系統(tǒng)，沒有高頻率的寫更新。MySQL、Redis、Mongodb 的高可用架構，基本上官方開源提供的都是這種模式。

4. TuGraph-DB 高可用架構—Raft 共識算法

針對上述缺點，我們選用了 Raft 算法來實現(xiàn)高可用架構。Raft 算法的優(yōu)點包括：

• 首先，它保持了一主多備的易用性。它有一個強 leader 可以對外提供服務。
• 第二是一致性。一主多備的模式是通過定期復制的方式去進行數(shù)據(jù)備份。但是 Raft 算法采用的是日志復制方式，復制的是日志并不是數(shù)據(jù)，當寫請求的日志到來之后，會逐個按順序發(fā)送給每一個節(jié)點，當超過半數(shù)的節(jié)點達成一致之后才會提交，所以它不僅不會丟失數(shù)據(jù)，甚至也不會存在日志空洞或亂序的情況。
• 有了一致性的保證后，安全性也就有了保證，當超過半數(shù)的節(jié)點達成一致之后，才應用日志，這樣就能解決網(wǎng)絡分區(qū)延遲、丟包、冗余和亂序的錯誤。
• 基于一致性和安全性，它的可用性也就得到了保證，只要少于半數(shù)的節(jié)點宕機，即使主機宕機，也可以快速恢復應用，通過一次選舉的時間就可以重新選出一個 leader 對外提供服務。

PPT 右下角的表格是國標對于高可用系統(tǒng)的指標評估，RTO 和 RPO 分別是恢復時間指標和恢復點目標，有 6 個等級，TuGraph-DB 已經(jīng)達到了最高等級。當少量節(jié)點故障時，RPO 是 0，也就是沒有數(shù)據(jù)損失，數(shù)據(jù)恢復時間點指標是小于 15 秒。即使是在部署的時候，無論是在同城的兩中心、三中心，還是多地的多中心，都可以達成 RTO 小于 15 秒的標準。

二、TuGraph-DB 高可用架構與規(guī)劃

1. Server 架構設計—啟動集群

上面是我們選擇的一個基礎算法，下面介紹 TuGraph-DB 具體的高可用架構是怎樣設計的。通過一個 CASE 來進行講解。

首先建立一個集群，啟動集群的方式跟單機版幾乎是一致的，只不過要加上 enable_ha 參數(shù)和 ha_conf 參數(shù)去指定集群里面所有節(jié)點的 URL，并且要保證三個或者五個節(jié)點是可以進行通信的。在三個節(jié)點同時啟動后，最先啟動的節(jié)點的計時器會超時，把自己選成一個候選者，之后向其它節(jié)點發(fā)送一個投票請求，其它節(jié)點接收到請求之后，會返回給候選者一個 success 的 response，當超過半數(shù)之后，這個 leader 就當選了。一般來說，在同城的情況下，延遲不會超過 2 毫秒，在兩地的情況下，比如上海到深圳，最高延遲不會超過 30 毫秒，所以集群建立的時間和選舉的時間是非?？斓?。

2. Server 架構設計—請求同步

集群建立好之后，可以向其發(fā)送讀寫請求。發(fā)送讀請求非常簡單，client 發(fā)送一個讀請求給 TuGraph server，server 接到讀請求之后，去進行處理。圖中給出的一個 cypher 語句，是查詢圖中邊的 label 的數(shù)量。在 server 端，會對 cypher 語句進行解析，辨別它是一個只讀的請求，一旦確定就會直接發(fā)送給 TuGraph-DB，由 TuGraph-DB 進行響應。

寫請求會涉及到 DB 數(shù)據(jù)的變化。Client 發(fā)送給 server 之后，server 會通過一些自有的邏輯去判斷，如果是一個寫請求，那么它會傳給內(nèi)部的一個 raft node，這個 raft node 可以看作是一個 client。因為是三個節(jié)點，每個節(jié)點持有其它節(jié)點的一個 client，每個節(jié)點既是 server，也是 client。當收到這個請求之后，只有 leader 節(jié)點會處理寫請求。它并不會直接應用到 TuGraph-DB 上面，而是先調(diào)用客戶端把日志去發(fā)送給其它節(jié)點，當超過半數(shù)的節(jié)點響應之后，才會應用到 TuGraph-DB 內(nèi)部，保證寫請求日志的一致性。

在高可用集群使用過程中，有很多不可預知的情況，比如正好在應用日志的時候，集群突然掛了或者突然重啟了。即使這種情況發(fā)生的概率非常低，但在大規(guī)模應用中仍然有可能發(fā)生。因此，寫請求必須是冪等的，請求的 log index 必須是一致的，當它應用到 DB 里時，不能產(chǎn)生重復的提交。所以我們在 DB 內(nèi)部持有 log 的 index，當 client 由于超時重發(fā)或節(jié)點的狀態(tài)發(fā)生變化而重復提交時，都不會對 DB 狀態(tài)產(chǎn)生污染。

3. Server 架構設計—集群成員變更

接下來要考慮的是集群成員變更的情況。首先來看增加節(jié)點。增加的節(jié)點以 follower 的角色加入集群，和啟動的命令一致就可以將節(jié)點加入集群。增加節(jié)點時還需要同步日志。

再來看刪除節(jié)點的情況。我們?nèi)绻褂?Meta Server 去控制集群成員的變更，那么這個 Meta Server 也要是高可用的。如果這個 Meta Server 發(fā)生了宕機，會導致整體的不可用。為了簡化設計，我們直接讓 leader 去控制集群成員的變更。

要刪除節(jié)點時，可以直接調(diào)用下圖中給出的命令，讓節(jié)點離開集群。正常情況下是由 leader 向 follower 發(fā)送心跳，為了維護集群正常的狀態(tài)，follower 也會向 leader 發(fā)送心跳，讓 leader 感知到它的存在。當 follower 超過一定的時間沒有給 leader 發(fā)送心跳時，就會把這個 follower 從集群中去除，從而完成了集群成員的變更。

當然需要注意的是，比如有 7 個節(jié)點，不能同時刪掉 4 個節(jié)點，這就相當于有 4 個節(jié)點宕機了。

4. Server 架構設計—快照

前文中提到，加入 follower 時，需要同步日志。但是一個集群經(jīng)過長期的服務，日志一定是非常多的，如果每加入一個 follower，都從一年之前、兩年之前的日志開始同步，同步過來除了 Append，還需要應用到 Server 里面，是非常耗時的。所以需要定期對節(jié)點打快照，對數(shù)據(jù)庫狀態(tài)做一個保存。再去加入 follower 時，直接傳輸快照就可以了。

Tugraph-DB 不管是安裝快照還是打快照，都是非?？焖俚摹Ｒ驗?Tugraph-DB 底層支持 MVCC 多版本，生成快照的時候并不會去阻塞讀寫請求。

5. Client 架構設計

以上對 server 端的設計進行了介紹，接下來介紹 client 端的設計。Client 端最重要的有兩點，第一點是 client 必須持有集群中所有節(jié)點的連接，不能只有一個節(jié)點。既然持有所有節(jié)點的連接，也就是連接池，那么它必須要知道誰是 leader，所以 client 必須要支持在連接上這個集群的時候，自動定位到 leader，通過這種方式，只需要去指定集群中任意一個節(jié)點的 URL，就可以連接上整個集群，并自動找到集群中的 leader。

第二個重要的點就是負載均衡。因為 leader 數(shù)據(jù)是最全的，并且只有它能寫。但是整個高可用架構，并不只提供數(shù)據(jù)的安全性，還要提供讀寫的功能，并且能更好的利用硬件資源，所以我們要對讀請求做負載均衡，以輪詢的方式去循環(huán)地發(fā)送給每一個節(jié)點，來提高訪問性能。

6. 未來規(guī)劃

未來規(guī)劃，主要有三個方面。

第一個是 Witness 角色。這個角色起源于一個場景，假如一個企業(yè)沒有很多機器，比如只有兩臺機器，但是它又想用高可用的架構，那應該怎么辦？引入 Raft 擴展角色，就是 witness 角色，這個角色有一個特點，它只參與選舉，但是不參與日志復制。也就是可以在一個機器里面運行兩個節(jié)點，一個節(jié)點不復制日志，只參與選舉。那么在另外一個機器里面去運行一個節(jié)點，這樣兩臺機器就可以啟動高可用集群了。這樣不僅可以減少數(shù)據(jù)的傳輸量，而且可以提高可用性和性能，因為它不用應用日志了。

第二個是按需快照。大家在使用圖數(shù)據(jù)庫的時候，數(shù)據(jù)量可能是非常龐大的。比如我們內(nèi)部有一個 1.2T 的線上業(yè)務，當它去打 snapshot 的時候，時間非常長，大概要兩個小時。雖然它并不阻塞讀寫請求，但對性能的影響還是非常嚴重的，并且會放大存儲空間，原來數(shù)據(jù)是 1.2T，打完之后可能就變成 2.4T 了。所以我們希望改造 Raft 協(xié)議，去提供按需生成快照的功能，只有在 follower 加入節(jié)點的時候才進行快照，因為只有 follower 加入這個節(jié)點時需要快照來加速數(shù)據(jù)同步。

第三個是高可用工具鏈。因為 TuGraph-DB 的高可用功能是 3.6 版本才開源，它提供的工具鏈現(xiàn)在還有一些待完善的地方，比如在線導入，只提供了單機的功能，我們希望可以提供一個集群在線導入，這樣就不用去對多機執(zhí)行在線導入的功能了。還有快照生成工具，client 的接口完善等等。

三、TuGraph-DB 高可用集群部署與應用

1. TuGraph-DB 高可用（V3.6）

關于 TuGraph-DB 高可用集群的部署方式和 client 應用，相關文檔已經(jīng)放到了 tugraph-db.readthedocs.io 網(wǎng)站上。

現(xiàn)在支持 C++、Java 和 Python 多種版本的 client SDK。

2. 高可用集群部署

當原始數(shù)據(jù)一致的時候，可以直接指定 HA configure 參數(shù)啟動集群。當初始數(shù)據(jù)不一致的時候，假如有一個節(jié)點有數(shù)據(jù)，其它節(jié)點沒有數(shù)據(jù)，需要把數(shù)據(jù)同步到其它節(jié)點，但是又不能通過 SCP 傳，那么就可以通過初始數(shù)據(jù)不一致的方式去啟動。有數(shù)據(jù)的節(jié)點用 bootstrap 方式啟動，預先生成一個快照，然后其它節(jié)點以 follower 的身份加入集群，加入集群時會安裝快照，安裝快照之后才會進行選舉和 follower 身份的確認。

3. Client 連接應用

啟動完集群之后，前端會有一個高可用的列表，client 有直接方式和間接方式連接的區(qū)別，主要是考慮到在亞馬遜云部署和阿里云部署的區(qū)別。連接完了之后就可以去執(zhí)行請求，比如執(zhí)行寫請求的時候，要先寫到 leader 再同步到 follower，可以看到是有日志同步的。