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

作者：唐劉

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

關于 fdb 的研究，自己預計會有幾篇，這次是第一篇，來聊聊我最關注的一個問題 - fdb 是如何實現分布式事務的。

在開始介紹之前，要先說說 fdb 的關鍵組件。

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

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

Master 主要是用來協調寫子系統的，一個寫子系統包括 master，proxies，resolvers 和 transaction logs。Proxy，resolver 和 transaction log 是一個整體單元，如果任意一個失敗了，那么我們就會重新找一個來將他們全部替換。Master 會給 proxies 分配 commit versions，對數據進行分布，以及全局的流速控制。

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

對于一次事務提交，當只有下面操作全部完成，才能認為成功：

從 master 得到一個 commit version

使用 resolvers 來確定當前事務并沒有跟之前已經提交的事務沖突

讓 transaction 持久化到 transaction logs

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

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

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

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

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

開始事務

Clients 從 proxy 獲取一個 read version

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

Proxy 問其它的 proxies 當前最大的 commit version

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

讀流程

Client 根據 read version 以及需要訪問的數據的 key 或者 key range 找到對應的 storage servers

Storage server 接受到之后，如果發現 version 太老，結果返回錯誤。如果發現數據還不存在，就等或者超時

Storage server 會根據 read version 找對應的數據，并返回給 client

提交事務

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

Proxy 仍然是批量的接受請求

Proxy 將 range 切分并且發到不同的 resolvers，如果 resolver 判斷有沖突，結束事務

Proxy 通過 master 得到最近的 commit version

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

Transaction log servers 回復 proxy 說 log 已經落盤

Proxy 給 client 返回事務提交成功

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

根據提供的 version 和 tag 從 transaction logs 拿數據

將數據讀入到 storage server 的 Versioned data

將數據寫入 storage engine

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

上面僅僅是對 fdb 事務流程的簡單介紹，幾個 concern 的點：

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

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

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

后面我會詳盡的搗鼓折騰下 FoundationDB，做下 benchmark，也正在將它集成到我們的 YCSB 里面，畢竟對我來說，至少 fdb 那套 deterministic 理念是可以借鑒學習的。如果你對我們相關的 TiKV 工作感興趣，歡迎聯系我 tl@pingcap.com。