不久之前蜀涨，F(xiàn)oundationDB （后面用 fdb 簡化） 重新開源侍瑟，對于大家來說，這真的是一個非常好的消息莱预。我也在第一時間下載了 fdb 的源碼柠掂，開始研究，一方面是看我們能在什么方面能夠借鑒锁施，另一方面也是需要給一些朋友回答陪踩，TiKV 到底跟 fdb 有什么不一樣這樣的問題。
關(guān)于 fdb 的研究悉抵，自己預(yù)計會有幾篇肩狂，但也不確定，這次是第一篇姥饰，來聊聊我最關(guān)注的一個問題 - fdb 是如何實現(xiàn)分布式事務(wù)的傻谁。
關(guān)鍵組件
在開始介紹之前，要先說說 fdb 的關(guān)鍵組件列粪。
Coordinators
所有的 clients 和 servers 都是通過 cluster file 來連接到 fdb cluster审磁，而這個 cluster file 就包含的是 coordinators 的 IP:PORT 列表。所有的 clients 和 servers 都會使用 coordinators 連接到 cluster controller岂座。
Cluster Controller
Cluster controller 是通過選舉產(chǎn)生的（fdb 貌似使用的是 Paxos态蒂，這個后面會詳細研究一下）。Cluster Controller 就是控制整個集群的费什，它是所有進程的入口钾恢，會監(jiān)控進程是否掛掉，告訴某個進程相關(guān)的 role鸳址，以及在所有進程之間傳遞系統(tǒng)的信息瘩蚪。Clients 也通過 cluster controller 來實時的同步最新的 proxies。
Master
Master 主要是用來協(xié)調(diào)寫子系統(tǒng)的稿黍，一個寫子系統(tǒng)包括 master疹瘦，proxies，resolvers 和 transaction logs巡球。Proxy言沐，resolver 和 transaction log 是一個整體單元，如果任意一個失敗了辕漂，那么我們就會重新找一個來將他們?nèi)刻鎿Q呢灶。Master 會給 proxies 分配 commit versions，對數(shù)據(jù)進行分布钉嘹，以及全局的流速控制。
Proxies
Proxies 會提供 read versions鲸阻，提交事務(wù)以及跟蹤 storage servers 的 key ranges跋涣。如果要提供一個 read version缨睡，一個 proxy 會問其他所有的 proxies 當(dāng)前最大的 committed version，并且同步的檢查 transaction logs 并沒有被停止陈辱。Master 流速控制可能會減緩提供 read versions 的頻率奖年。
對于一次事務(wù)提交，當(dāng)只有下面操作全部完成沛贪，才能認為成功：
- 從 master 得到一個 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ù)據(jù)的路由表了。Proxies 也給 clients 提供相關(guān)的信息媚送，讓 clients 進行緩存中燥，如果緩存缺失，就從 proxies 重新更新塘偎。
Transaction Logs
Transaction logs 會按照 version 的順序接受 proxy 發(fā)過來的提交疗涉，并會使用 append only 的方式將修改的提交持久化到硬盤。在數(shù)據(jù)被寫入到磁盤的時候吟秩，也會通知 storage servers 有相關(guān)的修改操作咱扣，讓 storage servers 去獲取并且 apply 到 storage servers 里面。
Resolvers
Resolvers 用來確定不同事務(wù)的沖突涵防。當(dāng)一個事務(wù)的 read version闹伪，讀取了一個 key，在 commit 之前武学，另一個事務(wù)寫入了新的值祭往，這時候就會有沖突。 Resovler 會在內(nèi)存里面保存 5s 的所有寫入提交火窒，用來判斷沖突硼补，這也就是意味著，fdb 的事務(wù)執(zhí)行時間不能超過 5s熏矿。
Storage Servers
Storage servers 就是存放數(shù)據(jù)的地方已骇，fdb 會將數(shù)據(jù)按照 range 切分，存儲到不同的 storage servers 上面票编。Storage servers 會在內(nèi)存里面保存最近 5s 的修改（Versioned data）褪储，如果一個 client 的 read version 超過了 5s，那就會過期出錯了慧域。Storage server 有 ssd 和 memory 兩種鲤竹，ssd 其實用的是 sqlite3。
流程
上面大概介紹了 fdb 的關(guān)鍵組件昔榴，這里就先來說說事務(wù)辛藻。Clients 會先用一個 read version 讀取所有的數(shù)據(jù)碘橘，然后在本地修改，最后再將所有的修改一起提交到 proxies吱肌，這其實也就是一個樂觀事務(wù)模型痘拆。具體流程如下：
-
開始事務(wù)
- Clients 從 proxy 獲取一個 read version
- Proxy 會批量接受 clients 的請求，如果超過了限流控制氮墨，額外的請求會排隊
- 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ù)還不存在，就等或者超時粒褒。
- 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ù)據(jù)分布切分月杉，加上 tag刃跛，推送到 transaction log servers
- Transaction log servers 回復(fù) proxy 說 log 已經(jīng)落盤
- Proxy 給 client 返回事務(wù)提交成功
可以看到，整個流程還是很簡單的苛萎，這里還需要注意幾個后臺流程桨昙。一個是 storage server 從 transaction logs 讀取數(shù)據(jù)：
- 根據(jù)提供的 version 和 tag 從 transaction logs 拿數(shù)據(jù)
- 將數(shù)據(jù)讀入到 storage server 的 Versioned data
- 將數(shù)據(jù)寫入 storage engine
另一個就是 version 的更新，proxies 會定期的生成一個空的 commit request 來增加 commit version腌歉，這樣 transaction logs 和 storage servers 的 version 都能增加蛙酪，就能處理一個集群如果沒有任何寫入，后面新的讀取也能按照 version 讀到對應(yīng)的版本翘盖，不會無限制的等待桂塞。如果我的 read version 比當(dāng)前 storage server 的最大 version 要大，其實并不能保證讀到正確的數(shù)據(jù)馍驯。為啥會做這個阁危，主要是 fdb 用的時間戳來當(dāng)?shù)?version。
小結(jié)
上面僅僅是對 fdb 事務(wù)流程的簡單介紹汰瘫，幾個 concern 的點：
- Proxy 會跟其他的 proxies 交互問最大的 commit version狂打，如果 proxy 多了會不會有性能問題？
- Resolver 如果 range 太多會不會也有性能問題混弥？
可以看到趴乡，fdb 在 resolver 那邊其實就是將事務(wù)排隊了，所以雖然外面看起來是樂觀事務(wù)，但對于沖突嚴重的情況浙宜，性能也比較不錯官辽。之前我一直以為 resovler 會是個單點蛹磺，但后面知道 resolver 也是可以 scale 的粟瞬。而且 fdb 自己也說做了很多的優(yōu)化，保證了整個的性能萤捆。
后面我會詳盡的搗鼓折騰下 FoundationDB裙品，做下 benchmark，也正在將它集成到我們的 YCSB 里面俗或，畢竟對我來說市怎，至少 fdb 那套 deterministic 理念是可以借鑒學(xué)習(xí)的。如果你對我們相關(guān)的 TiKV 工作感興趣辛慰，歡迎聯(lián)系我 tl@pingcap.com区匠。
