摘要：就是控制整個(gè)集群的，它是所有進(jìn)程的入口，會監(jiān)控進(jìn)程是否掛掉，告訴某個(gè)進(jìn)程相關(guān)的，以及在所有進(jìn)程之間傳遞系統(tǒng)的信息。會給分配，對數(shù)據(jù)進(jìn)行分布，以及全局的流速控制。會提供，提交事務(wù)以及跟蹤的。用來確定不同事務(wù)的沖突。

作者：唐劉

不久之前，F(xiàn)oundationDB （后面用 fdb 簡化） 重新開源，對于大家來說，這真的是一個(gè)非常好的消息。我也在第一時(shí)間下載了 fdb 的源碼，開始研究，一方面是看我們能在什么方面能夠借鑒，另一方面也是需要給一些朋友回答，TiKV 到底跟 fdb 有什么不一樣這樣的問題。

關(guān)于 fdb 的研究，自己預(yù)計(jì)會有幾篇，這次是第一篇，來聊聊我最關(guān)注的一個(gè)問題 - fdb 是如何實(shí)現(xiàn)分布式事務(wù)的。

在開始介紹之前，要先說說 fdb 的關(guān)鍵組件。

所有的 clients 和 servers 都是通過 cluster file 來連接到 fdb cluster，而這個(gè) cluster file 就包含的是 coordinators 的 IP:PORT 列表。所有的 clients 和 servers 都會使用 coordinators 連接到 cluster controller。

Cluster controller 是通過選舉產(chǎn)生的（fdb 貌似使用的是 Paxos，這個(gè)后面會詳細(xì)研究一下）。Cluster Controller 就是控制整個(gè)集群的，它是所有進(jìn)程的入口，會監(jiān)控進(jìn)程是否掛掉，告訴某個(gè)進(jìn)程相關(guān)的 role，以及在所有進(jìn)程之間傳遞系統(tǒng)的信息。Clients 也通過 cluster controller 來實(shí)時(shí)的同步最新的 proxies。

Master 主要是用來協(xié)調(diào)寫子系統(tǒng)的，一個(gè)寫子系統(tǒng)包括 master，proxies，resolvers 和 transaction logs。Proxy，resolver 和 transaction log 是一個(gè)整體單元，如果任意一個(gè)失敗了，那么我們就會重新找一個(gè)來將他們?nèi)刻鎿Q。Master 會給 proxies 分配 commit versions，對數(shù)據(jù)進(jìn)行分布，以及全局的流速控制。

Proxies 會提供 read versions，提交事務(wù)以及跟蹤 storage servers 的 key ranges。如果要提供一個(gè) read version，一個(gè) proxy 會問其他所有的 proxies 當(dāng)前最大的 committed version，并且同步的檢查 transaction logs 并沒有被停止。Master 流速控制可能會減緩提供 read versions 的頻率。

對于一次事務(wù)提交，當(dāng)只有下面操作全部完成，才能認(rèn)為成功：

從 master 得到一個(gè) commit version

使用 resolvers 來確定當(dāng)前事務(wù)并沒有跟之前已經(jīng)提交的事務(wù)沖突

讓 transaction 持久化到 transaction logs

所有以 xff 開頭的 key 是系統(tǒng)保留前綴，用來存放系統(tǒng)的元信息。任何對這段 key range 的修改都會 通-- 過 resolvers 同步到所有的 proxies。元信息包括數(shù)據(jù)的 key ranges 以及哪些 storage servers 有這些 range，其實(shí)也就是數(shù)據(jù)的路由表了。Proxies 也給 clients 提供相關(guān)的信息，讓 clients 進(jìn)行緩存，如果緩存缺失，就從 proxies 重新更新。

Transaction logs 會按照 version 的順序接受 proxy 發(fā)過來的提交，并會使用 append only 的方式將修改的提交持久化到硬盤。在數(shù)據(jù)被寫入到磁盤的時(shí)候，也會通知 storage servers 有相關(guān)的修改操作，讓 storage servers 去獲取并且 apply 到 storage servers 里面。

Resolvers 用來確定不同事務(wù)的沖突。當(dāng)一個(gè)事務(wù)的 read version，讀取了一個(gè) key，在 commit 之前，另一個(gè)事務(wù)寫入了新的值，這時(shí)候就會有沖突。 Resovler 會在內(nèi)存里面保存 5s 的所有寫入提交，用來判斷沖突，這也就是意味著，fdb 的事務(wù)執(zhí)行時(shí)間不能超過 5s。

Storage servers 就是存放數(shù)據(jù)的地方，fdb 會將數(shù)據(jù)按照 range 切分，存儲到不同的 storage servers 上面。Storage servers 會在內(nèi)存里面保存最近 5s 的修改（Versioned data），如果一個(gè) client 的 read version 超過了 5s，那就會過期出錯了。Storage server 有 ssd 和 memory 兩種，ssd 其實(shí)用的是 sqlite3。

上面大概介紹了 fdb 的關(guān)鍵組件，這里就先來說說事務(wù)。Clients 會先用一個(gè) read version 讀取所有的數(shù)據(jù)，然后在本地修改，最后再將所有的修改一起提交到 proxies，這其實(shí)也就是一個(gè)樂觀事務(wù)模型。具體流程如下：

開始事務(wù)

Clients 從 proxy 獲取一個(gè) read version

Proxy 會批量接受 clients 的請求，如果超過了限流控制，額外的請求會排隊(duì)

Proxy 問其它的 proxies 當(dāng)前最大的 commit version

Proxy 返回最大的 commit version 作為 read version

讀流程

Client 根據(jù) read version 以及需要訪問的數(shù)據(jù)的 key 或者 key range 找到對應(yīng)的 storage servers

Storage server 接受到之后，如果發(fā)現(xiàn) version 太老，結(jié)果返回錯誤。如果發(fā)現(xiàn)數(shù)據(jù)還不存在，就等或者超時(shí)

Storage server 會根據(jù) read version 找對應(yīng)的數(shù)據(jù)，并返回給 client

提交事務(wù)

Client 將修改，read version 以及 read ranges 和 write ranges 提交給 proxy

Proxy 仍然是批量的接受請求

Proxy 將 range 切分并且發(fā)到不同的 resolvers，如果 resolver 判斷有沖突，結(jié)束事務(wù)

Proxy 通過 master 得到最近的 commit version

Proxy 將修改的數(shù)據(jù)按照實(shí)際的數(shù)據(jù)分布切分，加上 tag，推送到 transaction log servers

Transaction log servers 回復(fù) proxy 說 log 已經(jīng)落盤

Proxy 給 client 返回事務(wù)提交成功

可以看到，整個(gè)流程還是很簡單的，這里還需要注意幾個(gè)后臺流程。一個(gè)是 storage server 從 transaction logs 讀取數(shù)據(jù)：

根據(jù)提供的 version 和 tag 從 transaction logs 拿數(shù)據(jù)

將數(shù)據(jù)讀入到 storage server 的 Versioned data

將數(shù)據(jù)寫入 storage engine

另一個(gè)就是 version 的更新，proxies 會定期的生成一個(gè)空的 commit request 來增加 commit version，這樣 transaction logs 和 storage servers 的 version 都能增加，就能處理一個(gè)集群如果沒有任何寫入，后面新的讀取也能按照 version 讀到對應(yīng)的版本，不會無限制的等待。如果我的 read version 比當(dāng)前 storage server 的最大 version 要大，其實(shí)并不能保證讀到正確的數(shù)據(jù)。為啥會做這個(gè)，主要是 fdb 用的時(shí)間戳來當(dāng)?shù)?version。

上面僅僅是對 fdb 事務(wù)流程的簡單介紹，幾個(gè) concern 的點(diǎn)：

Proxy 會跟其他的 proxies 交互問最大的 commit version，如果 proxy 多了會不會有性能問題

Resolver 如果 range 太多會不會也有性能問題

可以看到，fdb 在 resolver 那邊其實(shí)就是將事務(wù)排隊(duì)了，所以雖然外面看起來是樂觀事務(wù)，但對于沖突嚴(yán)重的情況，性能也比較不錯。之前我一直以為 resovler 會是個(gè)單點(diǎn)，但后面知道 resolver 也是可以 scale 的。而且 fdb 自己也說做了很多的優(yōu)化，保證了整個(gè)的性能。

后面我會詳盡的搗鼓折騰下 FoundationDB，做下 benchmark，也正在將它集成到我們的 YCSB 里面，畢竟對我來說，至少 fdb 那套 deterministic 理念是可以借鑒學(xué)習(xí)的。如果你對我們相關(guān)的 TiKV 工作感興趣，歡迎聯(lián)系我 [email protected]。