什么是 SOFAJRaft？

SOFAJRaft 是一個基于 Raft 一致性算法的生產(chǎn)級高性能 Java 實(shí)現(xiàn)，支持 MULTI-RAFT-GROUP，適用于高負(fù)載低延遲的場景。 使用 SOFAJRaft 你可以專注于自己的業(yè)務(wù)領(lǐng)域，由 SOFAJRaft 負(fù)責(zé)處理所有與 Raft 相關(guān)的技術(shù)難題，并且 SOFAJRaft 非常易于使用，你可以通過幾個示例在很短的時間內(nèi)掌握它。

https://raft.github.io

SOFAJRaft 是從百度的 braft 移植而來，做了一些優(yōu)化和改進(jìn)，感謝百度 braft 團(tuán)隊(duì)開源了如此優(yōu)秀的 C++ Raft 實(shí)現(xiàn)。

https://github.com/brpc/braft

基礎(chǔ)知識：分布式共識算法 (Consensus Algorithm)

如何理解分布式共識?

• 多個參與者某一件事一致 ：一件事，一個結(jié)論
• 已達(dá)成一致的結(jié)論，不可推翻

有哪些分布式共識算法?

• Paxos：被認(rèn)為是分布式共識算法的根本，其他都是其變種，但是 Paxos 論文中只給出了單個提案的過程，并沒有給出復(fù)制狀態(tài)機(jī)中需要的 multi-paxos 的相關(guān)細(xì)節(jié)的描述，實(shí)現(xiàn) Paxos 具有很高的工程復(fù)雜度（如多點(diǎn)可寫，允許日志空洞等）。
• Zab：被應(yīng)用在 Zookeeper 中，業(yè)界使用廣泛，但沒有抽象成通用的 library。
• Raft：以容易理解著稱，業(yè)界也涌現(xiàn)出很多 Raft 實(shí)現(xiàn)，比如大名鼎鼎的 etcd, braft, tikv 等。

什么是 Raft？

Raft 是一種更易于理解的分布式共識算法，核心協(xié)議本質(zhì)上還是師承 Paxos 的精髓，不同的是依靠 Raft 模塊化的拆分以及更加簡化的設(shè)計，Raft 協(xié)議相對更容易實(shí)現(xiàn)。

https://raft.github.io/

模塊化的拆分主要體現(xiàn)在：Raft 把一致性協(xié)議劃分為 Leader 選舉、MemberShip 變更、日志復(fù)制、Snapshot 等幾個幾乎完全解耦的模塊。

更加簡化的設(shè)計則體現(xiàn)在：Raft 不允許類似 Paxos 中的亂序提交、簡化系統(tǒng)中的角色狀態(tài)（只有 Leader、Follower、Candidate 三種角色）、限制僅 Leader 可寫入、使用隨機(jī)化的超時時間來設(shè)計 Leader Election 等等。

特點(diǎn)：Strong Leader

1. 系統(tǒng)中必須存在且同一時刻只能有一個 Leader，只有 Leader 可以接受 Clients 發(fā)過來的請求；
2. Leader 負(fù)責(zé)主動與所有 Followers 通信，負(fù)責(zé)將“提案”發(fā)送給所有 Followers，同時收集多數(shù)派的 Followers 應(yīng)答；
3. Leader 還需向所有 Followers 主動發(fā)送心跳維持領(lǐng)導(dǎo)地位(保持存在感)。

一句話總結(jié) Strong Leader: "你們不要 BB! 按我說的做，做完了向我匯報!"。

另外，身為 Leader 必須保持一直 BB(heartbeat) 的狀態(tài)，否則就會有別人跳出來想要 BB 。

Raft 中的基本概念

篇幅有限，這里只對 Raft 中的幾個概念做一個簡單介紹，詳細(xì)請參考 Raft paper。

https://raft.github.io/raft.pdf

Raft-node 的 3 種角色/狀態(tài)

1. Follower：完全被動，不能發(fā)送任何請求，只接受并響應(yīng)來自 Leader 和 Candidate 的 Message，每個節(jié)點(diǎn)啟動后的初始狀態(tài)一定是 Follower；
2. Leader：處理所有來自客戶端的請求，以及復(fù)制 Log 到所有 Followers；
3. Candidate：用來競選一個新 Leader （Candidate 由 Follower 觸發(fā)超時而來）。

Message 的 3 種類型

1. RequestVote RPC：由 Candidate 發(fā)出，用于發(fā)送投票請求；
2. AppendEntries (Heartbeat) RPC：由 Leader 發(fā)出，用于 Leader 向 Followers 復(fù)制日志條目，也會用作 Heartbeat （日志條目為空即為 Heartbeat）；
3. InstallSnapshot RPC：由 Leader 發(fā)出，用于快照傳輸，雖然多數(shù)情況都是每個服務(wù)器獨(dú)立創(chuàng)建快照，但是Leader 有時候必須發(fā)送快照給一些落后太多的 Follower，這通常發(fā)生在 Leader 已經(jīng)丟棄了下一條要發(fā)給該Follower 的日志條目(Log Compaction 時清除掉了) 的情況下。

任期邏輯時鐘

1. 時間被劃分為一個個任期 (term)，term id 按時間軸單調(diào)遞增；
2. 每一個任期的開始都是 Leader 選舉，選舉成功之后，Leader 在任期內(nèi)管理整個集群，也就是 “選舉 + 常規(guī)操作”；
3. 每個任期最多一個 Leader，可能沒有 Leader (spilt-vote 導(dǎo)致)。

本圖出自《Raft: A Consensus Algorithm for Replicated Logs》

什么是 SOFAJRaft？

SOFAJRaft 是一個基于 Raft 一致性算法的生產(chǎn)級高性能 Java 實(shí)現(xiàn)，支持 MULTI-RAFT-GROUP，適用于高負(fù)載低延遲的場景。 使用 SOFAJRaft 你可以專注于自己的業(yè)務(wù)領(lǐng)域，由 SOFAJRaft 負(fù)責(zé)處理所有與 Raft 相關(guān)的技術(shù)難題，并且 SOFAJRaft 非常易于使用，你可以通過幾個示例在很短的時間內(nèi)掌握它。

https://github.com/brpc/braft

SOFAJRaft 是從百度的 braft 移植而來，做了一些優(yōu)化和改進(jìn)，感謝百度 braft 團(tuán)隊(duì)開源了如此優(yōu)秀的 C++ Raft 實(shí)現(xiàn)。

SOFAJRaft 整體功能&性能優(yōu)化

功能支持

1.Leader election：Leader 選舉，這個不多說，上面已介紹過 Raft 中的 Leader 機(jī)制。

2.Log replication and recovery：日志復(fù)制和日志恢復(fù)。

1）Log replication 就是要保證已經(jīng)被 commit 的數(shù)據(jù)一定不會丟失，即一定要成功復(fù)制到多數(shù)派。

2）Log recovery 包含兩個方面：

3）Current term 日志恢復(fù)：主要針對一些 Follower 節(jié)點(diǎn)重啟加入集群或者是新增 Follower 節(jié)點(diǎn)后如何追日志；

4）Prev term 日志恢復(fù)：主要針對 Leader 切換前后的日志一致性。

3.Snapshot and log compaction：定時生成 snapshot，實(shí)現(xiàn) log compaction 加速啟動和恢復(fù)，以及 InstallSnapshot 給 Followers 拷貝數(shù)據(jù)，如下圖：

本圖出自《In Search of an Understandable Consensus Algorithm》

4.Membership change：用于集群線上配置變更，比如增加節(jié)點(diǎn)、刪除節(jié)點(diǎn)、替換節(jié)點(diǎn)等。

5.Transfer leader：主動變更 leader，用于重啟維護(hù)，leader 負(fù)載平衡等。

6.Symmetric network partition tolerance：對稱網(wǎng)絡(luò)分區(qū)容忍性。

如上圖 S1 為當(dāng)前 leader，網(wǎng)絡(luò)分區(qū)造成 S2 不斷增加本地 term，為了避免網(wǎng)絡(luò)恢復(fù)后 S2 發(fā)起選舉導(dǎo)致正在良心 工作的 leader step-down，從而導(dǎo)致整個集群重新發(fā)起選舉，SOFAJRaft 中增加了 pre-vote 來避免這個問題的發(fā)生。

SOFAJRaft 中在 request-vote 之前會先進(jìn)行 pre-vote(currentTerm + 1, lastLogIndex, lastLogTerm)，多數(shù)派成功后才會轉(zhuǎn)換狀態(tài)為 candidate 發(fā)起真正的 request-vote，所以分區(qū)后的節(jié)點(diǎn)，pre-vote 不會成功，也就不會導(dǎo)致集群一段時間內(nèi)無法正常提供服務(wù)。

7.Asymmetric network partition tolerance：非對稱網(wǎng)絡(luò)分區(qū)容忍性。

如上圖 S1 為當(dāng)前 leader，S2 不斷超時觸發(fā)選主，S3 提升 term 打斷當(dāng)前 lease，從而拒絕 leader 的更新。

1. 在 SOFAJRaft 中增加了一個 tick 的檢查，每個 follower 維護(hù)一個時間戳記錄下收到 leader 上數(shù)據(jù)更新的時間(也包括心跳)，只有超過 election timeout 之后才允許接受 request-vote 請求。

8.Fault tolerance：容錯性，少數(shù)派故障不影響系統(tǒng)整體可用性，包括但不限于：

1）機(jī)器掉電

2）強(qiáng)殺應(yīng)用

3）慢節(jié)點(diǎn)(GC, OOM 等)

4）網(wǎng)絡(luò)故障

5）其他各種奇葩原因?qū)е?raft 節(jié)點(diǎn)無法正常工作

9.Workaround when quorate peers are dead：多數(shù)派故障時，整個 grop 已不具備可用性，安全的做法是等待多數(shù)節(jié)點(diǎn)恢復(fù)，只有這樣才能保證數(shù)據(jù)安全；但是如果業(yè)務(wù)更加追求系統(tǒng)可用性，可以放棄數(shù)據(jù)一致性的話，SOFAJRaft 提供了手動觸發(fā) reset_peers 的指令以迅速重建整個集群，恢復(fù)集群可用。

10.Metrics：SOFAJRaft 內(nèi)置了基于 Metrics 類庫的性能指標(biāo)統(tǒng)計，具有豐富的性能統(tǒng)計指標(biāo)，利用這些指標(biāo)數(shù)據(jù)可以幫助用戶更容易找出系統(tǒng)性能瓶頸。

11.Jepsen：除了幾百個單元測試以及部分 chaos 測試之外, SOFAJRaft 還使用 jepsen 這個分布式驗(yàn)證和故障注入測試框架模擬了很多種情況，都已驗(yàn)證通過：

1）隨機(jī)分區(qū)，一大一小兩個網(wǎng)絡(luò)分區(qū)

2）隨機(jī)增加和移除節(jié)點(diǎn)

3）隨機(jī)停止和啟動節(jié)點(diǎn)

4）隨機(jī) kill -9 和啟動節(jié)點(diǎn)

5）隨機(jī)劃分為兩組，互通一個中間節(jié)點(diǎn)，模擬分區(qū)情況

6）隨機(jī)劃分為不同的 majority 分組

性能優(yōu)化

除了功能上的完整性，SOFAJRaft 還做了很多性能方面的優(yōu)化，這里有一份 KV 場景（get/put）的 Benchmark 數(shù)據(jù), 在小數(shù)據(jù)包，讀寫比例為 9:1，保證線性一致讀的場景下，三副本***可以達(dá)到 40w+ 的 ops。

這里挑重點(diǎn)介紹幾個優(yōu)化點(diǎn)：

1. Batch： 我們知道互聯(lián)網(wǎng)兩大優(yōu)化法寶便是 Cache 和 Batch，SOFAJRaft 在 Batch 上花了較大心思，整個鏈路幾乎都是 Batch 的，依靠 disruptor 的 MPSC 模型批量消費(fèi)，對整體性能有著極大的提升，包括但不限于：
2. 批量提交 task
3. 批量網(wǎng)絡(luò)發(fā)送
4. 本地 IO batch 寫入
5. 要保證日志不丟，一般每條 log entry 都要進(jìn)行 fsync 同步刷盤，比較耗時，SOFAJRaft 中做了合并寫入的優(yōu)化。
6. 批量應(yīng)用到狀態(tài)機(jī)
7. 需要說明的是，雖然 SOFAJRaft 中大量使用了 Batch 技巧，但對單個請求的延時并無任何影響，SOFAJRaft 中不會對請求做延時的攢批處理。
8. Replication pipeline：流水線復(fù)制，通常 Leader 跟 Followers 節(jié)點(diǎn)的 Log 同步是串行 Batch 的方式，每個 Batch 發(fā)送之后需要等待 Batch 同步完成之后才能繼續(xù)發(fā)送下一批(ping-pong)，這樣會導(dǎo)致較長的延遲。SOFAJRaft 中通過 Leader 跟 Followers 節(jié)點(diǎn)之間的 pipeline 復(fù)制來改進(jìn)，非常有效降低了數(shù)據(jù)同步的延遲, 提高吞吐。經(jīng)我們測試，開啟 pipeline 可以將吞吐提升 30% 以上，詳細(xì)數(shù)據(jù)請參照 Benchmark。
9. Append log in parallel：在 SOFAJRaft 中 Leader 持久化 log entries 和向 Followers 發(fā)送 log entries 是并行的。
10. Fully concurrent replication：Leader 向所有 Follwers 發(fā)送 Log 也是完全相互獨(dú)立和并發(fā)的。
11. Asynchronous：SOFAJRaft 中整個鏈路幾乎沒有任何阻塞，完全異步的，是一個完全的 callback 編程模型。
12. ReadIndex：優(yōu)化 Raft read 走 Raft log 的性能問題，每次 read，僅記錄 commitIndex，然后發(fā)送所有 peers heartbeat 來確認(rèn) Leader 身份，如果 Leader 身份確認(rèn)成功，等到 appliedIndex >= commitIndex，就可以返回 Client read 了，基于 ReadIndex Follower 也可以很方便的提供線性一致讀，不過 commitIndex 是需要從 Leader 那里獲取，多了一輪 RPC；關(guān)于線性一致讀文章后面會詳細(xì)分析。
13. Lease Read：SOFAJRaft 還支持通過租約 (lease) 保證 Leader 的身份，從而省去了 ReadIndex 每次 heartbeat 確認(rèn) Leader 身份，性能更好，但是通過時鐘維護(hù) lease 本身并不是絕對的安全（時鐘漂移問題，所以 SOFAJRaft 中默認(rèn)配置是 ReadIndex，因?yàn)橥ǔＧ闆r下 ReadIndex 性能已足夠好。

SOFAJRaft 設(shè)計

1. Node：Raft 分組中的一個節(jié)點(diǎn)，連接封裝底層的所有服務(wù)，用戶看到的主要服務(wù)接口，特別是 apply(task)用于向 raft group 組成的復(fù)制狀態(tài)機(jī)集群提交新任務(wù)應(yīng)用到業(yè)務(wù)狀態(tài)機(jī)。
2. 存儲：上圖靠下的部分均為存儲相關(guān)。
3. Log 存儲，記錄 Raft 用戶提交任務(wù)的日志，將日志從 Leader 復(fù)制到其他節(jié)點(diǎn)上。
4. LogStorage 是存儲實(shí)現(xiàn)，默認(rèn)實(shí)現(xiàn)基于 RocksDB 存儲，你也可以很容易擴(kuò)展自己的日志存儲實(shí)現(xiàn)；
5. LogManager 負(fù)責(zé)對底層存儲的調(diào)用，對調(diào)用做緩存、批量提交、必要的檢查和優(yōu)化。
6. Metadata 存儲，元信息存儲，記錄 Raft 實(shí)現(xiàn)的內(nèi)部狀態(tài)，比如當(dāng)前 term、投票給哪個節(jié)點(diǎn)等信息。
7. Snapshot 存儲，用于存放用戶的狀態(tài)機(jī) snapshot 及元信息，可選：
8. SnapshotStorage 用于 snapshot 存儲實(shí)現(xiàn)；
9. SnapshotExecutor 用于 snapshot 實(shí)際存儲、遠(yuǎn)程安裝、復(fù)制的管理。
10. 狀態(tài)機(jī)
11. StateMachine：用戶核心邏輯的實(shí)現(xiàn)，核心是 onApply(Iterator) 方法, 應(yīng)用通過 Node#apply(task) 提交的日志到業(yè)務(wù)狀態(tài)機(jī)；
12. FSMCaller:封裝對業(yè)務(wù) StateMachine 的狀態(tài)轉(zhuǎn)換的調(diào)用以及日志的寫入等,一個有限狀態(tài)機(jī)的實(shí)現(xiàn),做必要的檢查、請求合并提交和并發(fā)處理等。
13. 復(fù)制
14. Replicator：用于 Leader 向 Followers 復(fù)制日志，也就是 Raft 中的 AppendEntries 調(diào)用，包括心跳存活檢查等；
15. ReplicatorGroup：用于單個 Raft group 管理所有的 replicator，必要的權(quán)限檢查和派發(fā)。
16. RPC：RPC 模塊用于節(jié)點(diǎn)之間的網(wǎng)絡(luò)通訊
17. RPC Server：內(nèi)置于 Node 內(nèi)的 RPC 服務(wù)器，接收其他節(jié)點(diǎn)或者客戶端發(fā)過來的請求，轉(zhuǎn)交給對應(yīng)服務(wù)處理；
18. RPC Client：用于向其他節(jié)點(diǎn)發(fā)起請求，例如投票、復(fù)制日志、心跳等。
19. KV Store：KV Store 是各種 Raft 實(shí)現(xiàn)的一個典型應(yīng)用場景，SOFAJRaft 中包含了一個嵌入式的分布式 KV 存儲實(shí)現(xiàn)（SOFAJRaft-RheaKV）。

SOFAJRaft Group

單個節(jié)點(diǎn)的 SOFAJRaft-node 是沒什么實(shí)際意義的，下面是三副本的 SOFAJRaft 架構(gòu)圖：

SOFAJRaft Multi Group

單個 Raft group 是無法解決大流量的讀寫瓶頸的，SOFAJRaft 自然也要支持 multi-raft-group。

SOFAJRaft 實(shí)現(xiàn)細(xì)節(jié)解析之高效的線性一致讀

什么是線性一致讀? 所謂線性一致讀，一個簡單的例子就是在 t1 的時刻我們寫入了一個值，那么在 t1 之后，我們一定能讀到這個值，不可能讀到 t1 之前的舊值 (想想 Java 中的 volatile 關(guān)鍵字，說白了線性一致讀就是在分布式系統(tǒng)中實(shí)現(xiàn) Java volatile 語義)。

如上圖 Client A、B、C、D 均符合線性一致讀，其中 D 看起來是 stale read，其實(shí)并不是，D 請求橫跨了 3 個階段，而讀可能發(fā)生在任意時刻，所以讀到 1 或 2 都行。

重要：接下來的討論均基于一個大前提，就是業(yè)務(wù)狀態(tài)機(jī)的實(shí)現(xiàn)必須是滿足線性一致性的，簡單說就是也要具有 Java volatile 的語義。

1. 要實(shí)現(xiàn)線性一致讀，首先我們簡單直接一些，是否可以直接從當(dāng)前 Leader 節(jié)點(diǎn)讀?
2. 仔細(xì)一想，這顯然行不通，因?yàn)槟銦o法確定這一刻當(dāng)前的 "Leader" 真的是 Leader，比如在網(wǎng)絡(luò)分區(qū)的情況下，它可能已經(jīng)被推翻王朝卻不自知。
3. 最簡單易懂的實(shí)現(xiàn)方式：同 “寫” 請求一樣，“讀” 請求也走一遍 Raft 協(xié)議 (Raft Log)。

本圖出自《Raft: A Consensus Algorithm for Replicated Logs》

這一定是可以的，但性能上顯然不會太出色，走 Raft Log 不僅僅有日志落盤的開銷，還有日志復(fù)制的網(wǎng)絡(luò)開銷，另外還有一堆的 Raft “讀日志” 造成的磁盤占用開銷，這在讀比重很大的系統(tǒng)中通常是無法被接受的。

1. ReadIndex Read
2. 這是 Raft 論文中提到的一種優(yōu)化方案，具體來說：
3. Leader 將自己當(dāng)前 Log 的 commitIndex 記錄到一個 Local 變量 ReadIndex 里面；
4. 接著向 Followers 發(fā)起一輪 heartbeat，如果半數(shù)以上節(jié)點(diǎn)返回了對應(yīng)的 heartbeat response，那么 Leader 就能夠確定現(xiàn)在自己仍然是 Leader (證明了自己是自己)；
5. Leader 等待自己的狀態(tài)機(jī)執(zhí)行，直到 applyIndex 超過了 ReadIndex，這樣就能夠安全的提供 Linearizable Read 了，也不必管讀的時刻是否 Leader 已飄走 (思考：為什么等到 applyIndex 超過了 ReadIndex 就可以執(zhí)行讀請求?)；
6. Leader 執(zhí)行 read 請求，將結(jié)果返回給 Client。
7. 通過ReadIndex，也可以很容易在 Followers 節(jié)點(diǎn)上提供線性一致讀：
8. Follower 節(jié)點(diǎn)向 Leader 請求***的 ReadIndex；
9. Leader 執(zhí)行上面前 3 步的過程(確定自己真的是 Leader)，并返回 ReadIndex 給 Follower；
10. Follower 等待自己的 applyIndex 超過了 ReadIndex；
11. Follower 執(zhí)行 read 請求，將結(jié)果返回給 Client。（SOFAJRaft 中可配置是否從 Follower 讀取，默認(rèn)不打開）
12. ReadIndex小結(jié)：
13. 相比較于走 Raft Log 的方式，ReadIndex 省去了磁盤的開銷，能大幅度提升吞吐，結(jié)合 SOFAJRaft 的 batch + pipeline ack + 全異步機(jī)制，三副本的情況下 Leader 讀的吞吐可以接近于 RPC 的吞吐上限；
14. 延遲取決于多數(shù)派中最慢的一個 heartbeat response，理論上對于降低延時的效果不會非常顯著。
15. Lease Read
16. Lease Read 與 ReadIndex 類似，但更進(jìn)一步，不僅省去了 Log，還省去了網(wǎng)絡(luò)交互。它可以大幅提升讀的吞吐也能顯著降低延時。
17. 基本的思路是 Leader 取一個比 election timeout 小的租期(***小一個數(shù)量級)，在租約期內(nèi)不會發(fā)生選舉，這就確保了 Leader 不會變，所以可以跳過 ReadIndex 的第二步，也就降低了延時?？梢钥吹?Lease Read 的正確性和時間是掛鉤的，因此時間的實(shí)現(xiàn)至關(guān)重要，如果時鐘漂移嚴(yán)重，這套機(jī)制就會有問題。
18. 實(shí)現(xiàn)方式：
19. 定時 heartbeat 獲得多數(shù)派響應(yīng)，確認(rèn) Leader 的有效性 (在 SOFAJRaft 中默認(rèn)的 heartbeat 間隔是 election timeout 的十分之一)；
20. 在租約有效時間內(nèi)，可以認(rèn)為當(dāng)前 Leader 是 Raft Group 內(nèi)的唯一有效 Leader，可忽略 ReadIndex 中的 heartbeat 確認(rèn)步驟(2)；
21. Leader 等待自己的狀態(tài)機(jī)執(zhí)行，直到 applyIndex 超過了 ReadIndex，這樣就能夠安全的提供 Linearizable Read 了 。

在 SOFAJRaft 中發(fā)起一次線性一致讀請求的代碼展示：

// KV 存儲實(shí)現(xiàn)線性一致讀 
public void readFromQuorum(String key, AsyncContext asyncContext) { 
 // 請求 ID 作為請求上下文傳入 
 byte[] reqContext = new byte[4]; 
 Bits.putInt(reqContext, 0, requestId.incrementAndGet()); 
 // 調(diào)用 readIndex 方法, 等待回調(diào)執(zhí)行 
 this.node.readIndex(reqContext, new ReadIndexClosure() { 
 @Override 
 public void run(Status status, long index, byte[] reqCtx) { 
 if (status.isOk()) { 
 try { 
 // ReadIndexClosure 回調(diào)成功，可以從狀態(tài)機(jī)讀取***數(shù)據(jù)返回 
 // 如果你的狀態(tài)實(shí)現(xiàn)有版本概念，可以根據(jù)傳入的日志 index 編號做讀取 
 asyncContext.sendResponse(new ValueCommand(fsm.getValue(key))); 
 } catch (KeyNotFoundException e) { 
 asyncContext.sendResponse(GetCommandProcessor.createKeyNotFoundResponse()); 
 } 
 } else { 
 // 特定情況下，比如發(fā)生選舉，該讀請求將失敗 
 asyncContext.sendResponse(new BooleanCommand(false, status.getErrorMsg())); 
 } 
 } 
 }); 
} 

應(yīng)用場景

1. Leader 選舉；
2. 分布式鎖服務(wù)，比如 Zookeeper，在 SOFAJRaft 中的 RheaKV 模塊提供了完整的分布式鎖實(shí)現(xiàn)；
3. 高可靠的元信息管理，可直接基于 SOFAJRaft-RheaKV 存儲；
4. 分布式存儲系統(tǒng)，如分布式消息隊(duì)列、分布式文件系統(tǒng)、分布式塊系統(tǒng)等等。

使用案例

1. RheaKV：基于 SOFAJRaft 實(shí)現(xiàn)的嵌入式、分布式、高可用、強(qiáng)一致的 KV 存儲類庫。
2. AntQ Streams QCoordinator：使用 SOFAJRaft 在 Coordinator 集群內(nèi)做選舉、使用 SOFAJRaft-RheaKV 做元信息存儲等功能。
3. Schema Registry：高可靠 schema 管理服務(wù)，類似 kafka schema registry，存儲部分基于 SOFAJRaft-RheaKV。
4. SOFA 服務(wù)注冊中心元信息管理模塊：IP 數(shù)據(jù)信息注冊，要求寫數(shù)據(jù)達(dá)到各個節(jié)點(diǎn)一致，并且在少數(shù)派節(jié)點(diǎn)掛掉時保證不影響數(shù)據(jù)正常存儲。

實(shí)踐

一、基于 SOFAJRaft 設(shè)計一個簡單的 KV Store

二、基于 SOFAJRaft 的 RheaKV 的設(shè)計

功能名詞

PD

• 全局的中心總控節(jié)點(diǎn)，負(fù)責(zé)整個集群的調(diào)度，不需要自管理的集群可不啟用 PD (一個 PD 可管理多個集群，基于 clusterId 隔離)。

Store

• 集群中的一個物理存儲節(jié)點(diǎn)，一個 Store 包含一個或多個 Region。

Region

• 最小的 KV 數(shù)據(jù)單元，每個 Region 都有一個左閉右開的區(qū)間 [startKey, endKey), 可根據(jù)請求流量/負(fù)載/數(shù)據(jù)量大小等指標(biāo)自動分裂以及自動副本搬遷。

特點(diǎn)

• 嵌入式
• 強(qiáng)一致性
• 自驅(qū)動
• 自診斷, 自優(yōu)化, 自決策

以上幾點(diǎn)(尤其2、3) 基本都是依托于 SOFAJRaft 自身的功能來實(shí)現(xiàn)，詳細(xì)介紹請參考 SOFAJRaft 文檔 。

致謝

感謝 braft、etcd、tikv 貢獻(xiàn)了優(yōu)秀的 Raft 實(shí)現(xiàn)，SOFAJRaft 受益良多。