本文來自：https://www.infoq.cn/article/how-to-build-a-distributed-database
文章寫得很好，備份防丟失

在技術方面，我自己熱衷于 Open Source，寫了很多 Open Source 的東西，擅長的是 Infrastructure 領域。Infrastructure 領域現在范圍很廣，比如說很典型的分布式 Scheduler、Mesos、Kubernetes，另外它和 Microservices 所結合的東西也特別多。Infrastructure 領域還有比如 Database 有分 AP（分析型）和 TP（事務型），比如說很典型的大家知道的 Spark、Greenplum、Apache Phoenix 等等，這些都屬于在 AP 的，它們也會去嘗試支持有限的 TP。另外，還有一個比較有意思的就是 Kudu——Cloudera Open Source 的那個項目，它的目標很有意思：我不做最強的 AP 系統，也不做最強的 TP 系統，我選擇一個相對折中的方案。從文化哲學上看，它比較符合中國的中庸思想。

另外，我先后創建了 Codis、TiDB。去年 12 月份創建了 TiKV 這個 project，TiKV 在所有的 rust 項目里目前排名前三。

首先我們聊聊 Database 的歷史，在已經有這么多種數據庫的背景下我們為什么要創建另外一個數據庫；以及說一下現在方案遇到的困境，說一下 Google Spanner 和 F1、TiKV 和 TiDB，說一下架構的事情，在這里我們會重點聊一下 TiKV。因為我們產品的很多特性是 TiKV 提供的，比如說跨數據中心的復制、Transaction、auto-scale。

接下來聊一下為什么 TiKV 用 Raft 能實現所有這些重要的特性，以及 scale、MVCC 和事務模型。東西非常多，我今天不太可能把里面的技術細節都描述得特別細，因為幾乎每一個話題都可以找到一篇或者是多篇論文，所以詳細的技術問題大家可以單獨來找我聊。

后面再說一下我們現在遇到的窘境，就是大家常規遇到的分布式方案有哪些問題，比如 MySQL Sharding。我們創建了無數 MySQL Proxy，比如官方的 MySQL proxy、Youtube 的 Vitess、淘寶的 Cobar、TDDL 以及基于 Cobar 的 MyCAT、金山的 Kingshard、360 的 Atlas、京東的 JProxy，我在豌豆莢也寫了一個。可以說，隨便一個大公司都會造一個 MySQL Sharding 的方案。

1、為什么我們要創建另外一個數據庫？

昨天晚上我還跟一個同學聊到，基于 MySQL 的方案它的天花板在哪里，它的天花板特別明顯。有一個思路是能不能通過 MySQL 的 server 把 InnoDB 變成一個分布式數據庫，聽起來這個方案很完美，但是很快就會遇到天花板。因為 MySQL 生成的執行計劃是個單機的，它認為整個計劃的 cost 也是單機的，我讀取一行和讀取下一行之間的開銷是很小的，比如迭代 next row 可以立刻拿到下一行。實際上在一個分布式系統里面，這是不一定的。

另外，你把數據都拿回來計算這個太慢了，很多時候我們需要把我們的 expression 或者計算過程等等運算推下去，向上返回一個最終的計算結果，這個一定要用分布式的 plan，前面控制執行計劃的節點，它必須要理解下面是分布式的東西，才能生成最好的 plan，這樣才能實現最高的執行效率。

比如說你做一個 sum，你是一條條拿回來加，還是讓一堆機器一起算，最后給我一個結果。 例如我有 100 億條數據分布在 10 臺機器上，并行在這 10 臺機器我可能只拿到 10 個結果，如果把所有的數據每一條都拿回來，這就太慢了，完全喪失了分布式的價值。聊到 MySQL 想實現分布式，另外一個實現分布式的方案就是 Proxy。但是 Proxy 本身的天花板在那里，就是它不支持分布式的 transaction，它不支持跨節點的 join，它無法理解復雜的 plan，一個復雜的 plan 打到 Proxy 上面，Proxy 就傻了，我到底應該往哪一個節點上轉發呢，如果我涉及到 subquery sql 怎么辦？所以這個天花板是瞬間會到，在傳統模型下面的修改，很快會達不到我們的要求。

另外一個很重要的是，MySQL 支持的復制方式是半同步或者是異步，但是半同步可以降級成異步，也就是說任何時候數據出了問題你不敢切換，因為有可能是異步復制，有一部分數據還沒有同步過來，這時候切換數據就不一致了。前一陣子出現過某公司突然不能支付了這種事件，今年有很多這種類似的 case，所以微博上大家都在說“說好的異地多活呢？”……

為什么傳統的方案在這上面解決起來特別的困難，天花板馬上到了，基本上不可能解決這個問題。另外是多數據中心的復制和數據中心的容災，MySQL 在這上面是做不好的。

在前面三十年基本上是關系數據庫的時代，那個時代創建了很多偉大的公司，比如說 IBM、Oracle、微軟也有自己的數據庫，早期還有一個公司叫 Sybase，有一部分特別老的程序員同學在當年的教程里面還可以找到這些東西，但是現在基本上看不到了。

另外是 NoSQL。NoSQL 也是一度非常火，像 Cassandra、MongoDB 等等，這些都屬于在互聯網快速發展的時候創建這些能夠 scale 的方案，但 Redis scale 出來比較晚，所以很多時候大家把 Redis 當成一個 Cache，現在慢慢大家把它當成存儲不那么重要的數據的數據庫。因為它有了 scale 支持以后，大家會把更多的數據放在里面。

然后到了 2015，嚴格來講是到 2014 年到 2015 年之間，Raft 論文發表以后，真正的 NewSQL 的理論基礎終于完成了。我覺得 NewSQL 這個理論基礎，最重要的劃時代的幾篇論文，一個是谷歌的 Spanner，是在 2013 年初發布的；再就是 Raft 是在 2014 年上半年發布的。這幾篇相當于打下了分布式數據庫 NewSQL 的理論基礎，這個模型是非常重要的，如果沒有模型在上面是堆不起來東西的。說到現在，大家可能對于模型還是可以理解的，但是對于它的實現難度很難想象。

前面我大概提到了我們為什么需要另外一個數據庫，說到 Scalability 數據的伸縮，然后我們講到需要 SQL，比如你給我一個純粹的 key-velue 系統的 API，比如我要查找年齡在 10 歲到 20 歲之間的 email 要滿足一個什么要求的。如果只有 KV 的 API 這是會寫死人的，要寫很多代碼，但是實際上用 SQL 寫一句話就可以了，而且 SQL 的優化器對整個數據的分布是知道的，它可以很快理解你這個 SQL，然后會得到一個最優的 plan，他得到這個最優的 plan 基本上等價于一個真正理解 KV 每一步操作的人寫出來的程序。通常情況下，SQL 的優化器是為了更加了解或者做出更好的選擇。

另外一個就是 ACID 的事務，這是傳統數據庫必須要提供的基礎。以前你不提供 ACID 就不能叫數據庫，但是近些年大家寫一個內存的 map 也可以叫自己是數據庫。大家寫一個 append-only 文件，我們也可以叫只讀數據庫，數據庫的概念比以前極大的泛化了。

另外就是高可用和自動恢復，他們的概念是什么呢？有些人會有一些誤解，因為今天還有朋友在現場問到，出了故障，比如說一個機房掛掉以后我應該怎么做切換，怎么操作。這個實際上相當于還是上一代的概念，還需要人去干預，這種不算是高可用。

未來的高可用一定是系統出了問題馬上可以自動恢復，馬上可以變成可用。比如說一個機房掛掉了，十秒鐘不能支付，十秒鐘之后系統自動恢復了變得可以支付，即使這個數據中心再也不起來我整個系統仍然是可以支付的。Auto-Failover 的重要性就在這里。大家不希望在睡覺的時候被一個報警給拉起來，我相信大家以后具備這樣一個能力，5 分鐘以內的報警不用理會，掛掉一個機房，又掛掉一個機房，這種連續報警才會理。我們內部開玩笑說，希望大家都能睡個好覺，很重要的事情就是這個。

說完應用層的事情，現在很有很多業務，在應用層自己去分片，比如說我按照 user ID 在代碼里面分片，還有一部分是更高級一點我會用到一致性哈希。問題在于它的復雜度，到一定程度之后我自動的分庫，自動的分表，我覺得下一代數據庫是不需要理解這些東西的，不需要了解什么叫做分庫，不需要了解什么叫做分表，因為系統是全部自動搞定的。同時復雜度，如果一個應用不支持事務，那么在應用層去做，通常的做法是引入一個外部隊列，引入大量的程序機制和狀態轉換，A 狀態的時候允許轉換到 B 狀態，B 狀態允許轉換到 C 狀態。

舉一個簡單的例子，比如說在京東上買東西，先下訂單，支付狀態之后這個商品才能出庫，如果不是支付狀態一定不能出庫，每一步都有嚴格的流程。

2、Google Spanner / F1

說一下 Google 的 Spanner 和 F1，這是我非常喜歡的論文，也是我最近幾年看過很多遍的論文。 Google Spanner 已經強大到什么程度呢？Google Spanner 是全球分布的數據庫，在國內目前普遍做法叫做同城兩地三中心，它們的差別是什么呢？以 Google 的數據來講，谷歌比較高的級別是他們有 7 個副本，通常是美國保存 3 個副本，再在另外 2 個國家可以保存 2 個副本，這樣的好處是萬一美國兩個數據中心出了問題，那整個系統還能繼續可用，這個概念就是比如美國 3 個副本全掛了，整個數據都還在，這個數據安全級別比很多國家的安全級別還要高，這是 Google 目前做到的，這是全球分布的好處。

現在國內主流的做法是兩地三中心，但現在基本上都不能自動切換。大家可以看到很多號稱實現了兩地三中心或者異地多活，但是一出現問題都說不好意思這段時間我不能提供服務了。大家無數次的見到這種 case， 我就不列舉了。

Spanner 現在也提供一部分 SQL 特性。在以前，大部分 SQL 特性是在 F1 里面提供的，現在 Spanner 也在逐步豐富它的功能，Google 是全球第一個做到這個規模或者是做到這個級別的數據庫。事務支持里面 Google 有點黑科技（其實也沒有那么黑），就是它有GPS 時鐘和原子鐘。大家知道在分布式系統里面，比如說數千臺機器，兩個事務啟動先后順序，這個順序怎么界定 (事務外部一致性)。這個時候 Google 內部使用了 GPS 時鐘和原子鐘，正常情況下它會使用一個 GPS 時鐘的一個集群，就是說我拿的一個時間戳，并不是從一個 GPS 上來拿的時間戳，因為大家知道所有的硬件都會有誤差。如果這時候我從一個上拿到的 GPS 本身有點問題，那么你拿到的這個時鐘是不精確的。而 Google 它實際上是在一批 GPS 時鐘上去拿了能夠滿足 majority 的精度，再用時間的算法，得到一個比較精確的時間。大家知道 GPS 也不太安全，因為它是美國軍方的，對于 Google 來講要實現比國家安全級別更高的數據庫，而 GPS 是可能受到干擾的，因為 GPS 信號是可以調整的，這在軍事用途上面很典型的，大家知道導彈的制導需要依賴 GPS，如果調整了 GPS 精度，那么導彈精度就廢了。所以他們還用原子鐘去校正 GPS，如果 GPS 突然跳躍了，原子鐘上是可以檢測到 GPS 跳躍的，這部分相對有一點黑科技，但是從原理上來講還是比較簡單，比較好理解的。

最開始它 Spanner 最大的用戶就是 Google 的 Adwords，這是 Google 最賺錢的業務，Google 就是靠廣告生存的，我們一直覺得 Google 是科技公司，但是他的錢是從廣告那來的，所以一定程度來講 Google 是一個廣告公司。Google 內部的方向先有了 Big table ，然后有了 MegaStore ，MegaStore 的下一代是 Spanner ，F1 是在 Spanner 上面構建的。

3、TiDB and TiKV

TiKV 和 TiDB 基本上對應 Google Spanner 和 Google F1，用 Open Source 方式重建。目前這兩個項目都開放在 GitHub 上面，兩個項目都比較火爆，TiDB 是更早一點開源的， 目前 TiDB 在 GitHub 上 有 4300 多個 Star，每天都在增長。

另外，對于現在的社會來講，我們覺得 Infrastructure 領域閉源的東西是沒有任何生存機會的。沒有任何一家公司，愿意把自己的身家性命壓在一個閉源的項目上。舉一個很典型的例子，在美國有一個數據庫叫 FoundationDB，去年被蘋果收購了。FoundationDB 之前和用戶簽的合約都是一年的合約。比如說，我給你服務周期是一年，現在我被另外一個公司收購了，我今年服務到期之后，我是滿足合約的。但是其他公司再也不能找它服務了，因為它現在不叫 FoundationDB 了，它叫 Apple 了，你不能找 Apple 給你提供一個 Enterprise service。

TiDB 和 TiKV 為什么是兩個項目，因為它和 Google 的內部架構對比差不多是這樣的：TiKV 對應的是 Spanner，TiDB 對應的是 F1 。F1 里面更強調上層的分布式的 SQL 層到底怎么做，分布式的 Plan 應該怎么做，分布式的 Plan 應該怎么去做優化。同時 TiDB 有一點做的比較好的是，它兼容了 MySQL 協議，當你出現了一個新型的數據庫的時候，用戶使用它是有成本的。大家都知道作為開發很討厭的一個事情就是，我要每個語言都寫一個 Driver，比如說你要支持 C++、你要支持 Java、你要支持 Go 等等，這個太累了，而且用戶還得改他的程序，所以我們選擇了一個更加好的東西兼容 MySQL 協議，讓用戶可以不用改。一會我會用一個視頻來演示一下，為什么一行代碼不改就可以用，用戶就能體會到 TiDB 帶來的所有的好處。

這個圖實際上是整個協議棧或者是整個軟件棧的實現。大家可以看到整個系統是高度分層的，從最底下開始是 RocksDB ，然后再上面用 Raft 構建一層可以被復制的 RocksDB ，在這一層的時候它還沒有 Transaction，但是整個系統現在的狀態是所有寫入的數據一定要保證它復制到了足夠多的副本。也就是說只要我寫進來的數據一定有足夠多的副本去 cover 它，這樣才比較安全，在一個比較安全的 Key-value store 上面， 再去構建它的多版本，再去構建它的分布式事務，然后在分布式事務構建完成之后，就可以輕松的加上 SQL 層，再輕松的加上 MySQL 協議的支持。然后，這兩天我比較好奇，自己寫了 MongoDB 協議的支持，然后我們可以用 MongoDB 的客戶端來玩，就是說協議這一層是高度可插拔的。TiDB 上可以在上面構建一個 MongoDB 的協議，相當于這個是構建一個 SQL 的協議，可以構建一個 NoSQL 的協議。這一點主要是用來驗證 TiKV 在模型上面的支持能力。

這是整個 TiKV 的架構圖，從這個看來，整個集群里面有很多 Node，比如這里畫了四個 Node ，分別對應了四個機器。每一個 Node 上可以有多個 Store，每個 Store 里面又會有很多小的 Region，就是說一小片數據，就是一個 Region 。從全局來看所有的數據被劃分成很多小片，每個小片默認配置是 64M，它已經足夠小，可以很輕松的從一個節點移到另外一個節點，Region 1 有三個副本，它分別在 Node1、Node 2 和 Node4 上面， 類似的 Region 2，Region 3 也是有三個副本。每個 Region 的所有副本組成一個 Raft Group，整個系統可以看到很多這樣的 Raft groups。

Raft 細節我不展開了，大家有興趣可以找我私聊或者看一下相應的資料。

因為整個系統里面我們可以看到上一張圖里面有很多 Raft group 給我們，不同 Raft group 之間的通訊都是有開銷的。所以我們有一個類似于 MySQL 的 group commit 機制 ，你發消息的時候實際上可以 share 同一個 connection ， 然后 pipeline + batch 發送，很大程度上可以省掉大量 syscall 的開銷。

另外，其實在一定程度上后面我們在支持壓縮的時候，也有非常大的幫助，就是可以減少數據的傳輸。對于整個系統而言，可能有數百萬的 Region，它的大小可以調整，比如說 64M、128M、256M，這個實際上依賴于整個系統里面當前的狀況。

比如說我們曾經在有一個用戶的機房里面做過測試，這個測試有一個香港機房和新加坡的機房。結果我們在做復制的時候，新加坡的機房大于 256M 就復制不過去，因為機房很不穩定，必須要保證數據切的足夠小，這樣才能復制過去。

如果一個 Region 太大以后我們會自動做 SPLIT，這是非常好玩的過程，有點像細胞的分裂。

然后 TiKV 的 Raft 實現，是從 etcd 里面 port 過來的，為什么要從 etcd 里面 port 過來呢？首先 TiKV 的 Raft 實現是用 Rust 寫的。作為第一個做到生產級別的 Raft 實現，所以我們從 etcd 里面把它用 Go 語言寫的 port 到這邊。

這個是 Raft 官網上面列出來的 TiKV 在里面的狀態，大家可以看到 TiKV 把所有 Raft 的 feature 都實現了。 比如說 Leader Election、Membership Changes，這個是非常重要的，整個系統的 scale 過程高度依賴 Membership Changes，后面我用一個圖來講這個過程。后面這個是 Log Compaction，這個用戶不太關心。

這是很典型的細胞分裂的圖，實際上 Region 的分裂過程和這個是類似的。

我們看一下擴容是怎么做的。

比如說以現在的系統假設，我們剛開始說只有三個節點，有 Region1 分別是在 1 、2、4，我用虛線連接起來代表它是一個 Raft group ，大家可以看到整個系統里面有三個 Raft group ，在每一個 Node 上面數據的分布是比較均勻的，在這個假設每一個 Region 是 64M ，相當于只有一個 Node 上面負載比其他的稍微大一點點。

一個在線視頻默認我們都是推薦 3 個副本或者 5 個副本的配置。Raft 本身有一個特點，如果一個 leader down 掉之后，其它的節點會選一個新的 leader ，那么這個新的 leader 會把它還沒有 commit 但已經 reply 過去的 log 做一個 commit ，然后會再做 apply ，這個有點偏 Raft 協議，細節我不講了。

復制數據的小的 Region，它實際上是跨多個數據中心做的復制。這里面最重要的一點是永遠不丟失數據，無論如何我保證我的復制一定是復制到 majority ，任何時候我只要對外提供服務，允許外面寫入數據一定要復制到 majority 。很重要的一點就是恢復的過程一定要是自動化的，我前面已經強調過，如果不能自動化恢復，那么中間的宕機時間或者對外不可服務的時間，便不是由整個系統決定的，這是相對回到了幾十年前的狀態。

4、MVCC

MVCC 我稍微仔細講一下這一塊。MVCC 的好處，它很好支持 Lock-free 的 snapshot read ，一會兒我有一個圖會展示 MVCC 是怎么做的。isolation level 就不講了， MySQL 里面的級別是可以調的，我們的 TiKV 有 SI，還有 SI+lock，默認是支持 SI 的這種隔離級別，然后你寫一個 select for update 語句，這個會自動的調整到 SI 加上 lock 這個隔離級別。這個隔離級別基本上和 SSI 是一致的。還有一個就是 GC 的問題，如果你的系統里面的數據產生了很多版本，你需要把這個比較老的數據給 GC 掉，比如說正常情況下我們是不刪除數據的， 你寫入一行，然后再寫入一行，不斷去 update 同一行的時候，每一次 update 會產生新的版本，新的版本就會在系統里存在，所以我們需要一個 GC 的模塊把比較老的數據給 GC 掉，實際上這個 GC 不是 Go 里面的 GC，不是 Java 的 GC，而是數據的 GC。

這是一個數據版本，大家可以看到我們的數據分成兩塊，一個是 meta，一個是 data。meta 相對于描述我的數據當前有多少個版本。大家可以看到綠色的部分，比如說我們的 meta key 是 A ，keyA 有三個版本，是 A1 、A2、A3，我們把 key 自己和 version 拼到一起。那我們用 A1、A2、A3 分別描述 A 的三個版本，那么就是 version 1/2/3。meta 里面描述，就是我的整個 key 相對應哪個版本，我想找到那個版本。比如說我現在要讀取 key A 的版本 10，但顯然現在版本 10 是沒有的，那么小于版本 10 最大的版本是 3，所以這時我就能讀取到 3，這是它的隔離級別決定的。關于 data，我剛才已經講過了。

5、分布式事務模型

接下來是分布式事務模型，其實是基于 Google Percolator，這是 Google 在 2006 發表的一篇論文，是 Google 在做內部增量處理的時候發現了這個方法，本質上還是二階段提交的。這使用的是一個樂觀鎖，比如說我提供一個 transaction ，我去改一個東西，改的時候是發布在本地的，并沒有馬上 commit 到數據存儲那一端，這個模型就是說，我修改的東西我馬上去 Lock 住，這個基本就是一個悲觀鎖。但如果到最后一刻我才提交出去，那么鎖住的這一小段的時間，這個時候實現的是樂觀鎖。樂觀鎖的好處就是當你沖突很小的時候可以得到非常好的性能，因為沖突特別小，所以我本地修改通常都是有效的，所以我不需要去 Lock ，不需要去 roll back 。本質上分布式事務就是 2PC (兩階段提交) 或者是 2+x PC，基本上沒有 1PC，除非你在別人的級別上做弱化。比如說我允許你讀到當前最新的版本，也允許你讀到前面的版本，書里面把這個叫做幻讀。如果你調到這個程度是比較容易做 1PC 的，這個實際上還是依賴用戶設定的隔離級別的，如果用戶需要更高的隔離級別，這個 1PC 就不太好做了。

這是一個路由，正常來講，大家可能會好奇一個 SQL 語句怎么最后會落到存儲層，然后能很好的運行，最后怎么能映射到 KV 上面，又怎么能路由到正確的節點，因為整個系統可能有上千個節點，你怎么能正確路由到那一個的節點。我們在 TiDB 有一個 TiKV driver ， 另外 TiKV 對外使用的是 Google Protocol Buffer 來作為通訊的編碼格式。

6、Placement Driver

來說一下 Placement Driver 。Placement Driver 是什么呢？整個系統里面有一個節點，它會時刻知道現在整個系統的狀態。比如說每個機器的負載，每個機器的容量，是否有新加的機器，新加機器的容量到底是怎么樣的，是不是可以把一部分數據挪過去，是不是也是一樣下線， 如果一個節點在十分鐘之內無法被其他節點探測到，我認為它已經掛了，不管它實際上是不是真的掛了，但是我也認為它掛了。因為這個時候是有風險的，如果這個機器萬一真的掛了，意味著你現在機器的副本數只有兩個，有一部分數據的副本數只有兩個。那么現在你必須馬上要在系統里面重新選一臺機器出來，它上面有足夠的空間，讓我現在只有兩個副本的數據重新再做一份新的復制，系統始終維持在三個副本。整個系統里面如果機器掛掉了，副本數少了，這個時候應該會被自動發現，馬上補充新的副本，這樣會維持整個系統的副本數。這是很重要的 ，為了避免數據丟失，必須維持足夠的副本數，因為副本數每少一個，你的風險就會再增加。這就是 Placement Driver 做的事情。

同時，Placement Driver 還會根據性能負載，不斷去 move 這個 data 。比如說你這邊負載已經很高了，一個磁盤假設有 100G，現在已經用了 80G，另外一個機器上也是 100G，但是他只用了 20G，所以這上面還可以有幾十 G 的數據，比如 40G 的數據，你可以 move 過去，這樣可以保證系統有很好的負載，不會出現一個磁盤巨忙無比，數據已經多的裝不下了，另外一個上面還沒有東西，這是 Placement Driver 要做的東西。

Raft 協議還提供一個很高級的特性叫 leader transfer。leader transfer 就是說在我不移動數據的時候，我把我的 leadership 給你，相當于從這個角度來講，我把流量分給你，因為我是 leader，所以數據會到我這來，但我現在把 leader 給你，我讓你來當 leader，原來打給我的請求會被打給你，這樣我的負載就降下來。這就可以很好的動態調整整個系統的負載，同時又不搬移數據。不搬移數據的好處就是，不會形成一個抖動。

7、MySQL Sharding

MySQL Sharding 我前面已經提到了它的各種天花板，MySQL Sharding 的方案很典型的就是解決基本問題以后，業務稍微復雜一點，你在 sharding 這一層根本搞不定。它永遠需要一個 sharding key，你必須要告訴我的 proxy，我的數據要到哪里找，對用戶來說是極不友好的，比如我現在是一個單機的，現在我要切入到一個分布式的環境，這時我必須要改我的代碼，我必須要知道我這個 key ，我的 row 應該往哪里 Sharding。如果是用 ORM ，這個基本上就沒法做這個事情了。有很多 ORM 它本身假設我后面只有一個 MySQL。但 TiDB 就可以很好的支持，因為我所有的角色都是對的，我不需要關注 Sharding 、分庫、分表這類的事情。

這里面有一個很重要的問題沒有提，我怎么做 DDL。如果這個表非常大的話，比如說我們有一百億吧，橫跨了四臺機器，這個時候你要給它做一個新的 Index，就是我要添加一個新的索引，這個時候你必須要不影響任何現有的業務，實際上這是多階段提交的算法，這個是 Google 和 F1 一起發出來那篇論文。

簡單來講是這樣的，先把狀態標記成 delete only ，delete only 是什么意思呢？因為在分布式系統里面，所有的系統對于 schema 的視野不是一致的，比如說我現在改了一個值，有一部分人發現這個值被改了，但是還有一部分人還沒有開始訪問這個，所以根本不知道它被改了。然后在一個分布系統里，你也不可能實時通知到所有人在同一時刻發現它改變了。比如說從有索引到沒有索引，你不能一步切過去，因為有的人認為它有索引，所以他給它建了一個索引，但是另外一個機器他認為它沒有索引，所以他就把數據給刪了，索引就留在里面了。這樣遇到一個問題，我通過索引找的時候告訴我有， 實際數據卻沒有了，這個時候一致性出了問題。比如說我 count 一個 email 等于多少的，我通過 email 建了一個索引，我認為它是在，但是 UID 再轉過去的時候可能已經不存在了。

比如說我先標記成 delete only，我刪除它的時候不管它現在有沒有索引，我都會嘗試刪除索引，所以我的數據是干凈的。如果我刪除掉的話，我不管結果是什么樣的，我嘗試去刪一下，可能這個索引還沒 build 出來，但是我仍然刪除，如果數據沒有了，索引一定沒有了，所以這可以很好的保持它的一致性。后面再類似于前面，先標記成 write only 這種方式，連續再迭代這個狀態，就可以迭代到一個最終可以對外公開的狀態。比如說當我迭代到一定程度的時候，我可以從后臺 build index ，比如說我一百億，正在操作的 index 會馬上 build，但是還有很多沒有 build index ，這個時候后臺不斷的跑 map-reduce 去 build index ，直到整個都 build 完成之后，再對外 public ，就是說我這個索引已經可用了，你可以直接拿索引來找，這個是非常經典的。在這個 Online，Asynchronous Schema Change in F1 paper 之前，大家都不知道這事該怎么做。

Proxy Sharding 的方案不支持分布式事務，更不用說跨數據中心的一致性事務了。 TiKV 很好的支持 transaction，剛才提到的 Raft 除了增加副本之外，還有 leader transfer，這是一個傳統的方案都無法提供的特性。以及它帶來的好處，當我瞬間平衡整個系統負載的時候，對外是透明的， 做 leader transfer 的時候并不需要移動數據，只是個簡單的 leader transfer 消息。

然后說一下如果大家想參與我們項目的話是怎樣的過程，因為整個系統是完全開源的，如果大家想參與其中任何一部分都可以，比如說我想參與到分布式 KV，可以直接貢獻到 TiKV。TiKV 需要寫 Rust，如果大家對這塊特別有激情可以體驗寫 Rust 的感覺 。

TiDB 是用 Go 寫的，Go 在中國的群眾基礎是非常多的，目前也有很多人在貢獻。整個 TiDB 和 TiKV 是高度協作的項目，因為 TiDB 目前還用到了 etcd ，我們在和 CoreOS 在密切的合作，也特別感謝 CoreOS 幫我們做了很多的支持，我們也為 CoreOS 的 etcd 提了一些 patch。同時，TiKV 使用 RocksDB ，所以我們也為 RocksDB 提了一些 patch 和 test，我們也非常感謝 Facebook RocksDB team 對我們項目的支持。

另外一個是 PD，就是我們前面提的 Placement Driver，它負責監控整個系統。這部分的算法比較好玩，大家如果有興趣的話，可以去自己控制整個集群的調度，它和 Kubernetes 或者是 Mesos 的調度算法是不一樣的，因為它調度的維度實際上比那個要更多。比如說磁盤的容量，你的 leader 的數量，你的網絡當前的使用情況，你的 IO 的負載和 CPU 的負載都可以放進去。同時你還可以讓它調度不要跨一個機房里面建多個副本。

總結

以上是生活随笔為你收集整理的怎样打造一个分布式数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。