怎樣打造一個分佈式數據庫——rocksDB, raft, mvcc，本質上是爲了解決跨數據中心的複製

摘自：http://www.infoq.com/cn/articles/how-to-build-a-distributed-database?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text

爲何咱們要建立另一個數據庫？

在前面三十年基本上是關係數據庫的時代，那個時代建立了不少偉大的公司，好比說 IBM、Oracle、微軟也有本身的數據庫，早期還有一個公司叫 Sybase，有一部分特別老的程序員同窗在當年的教程裏面還能夠找到這些東西，可是如今基本上看不到了。另外是 NoSQL。NoSQL 也是一度很是火，像 Cassandra、MongoDB 等等，這些都屬於在互聯網快速發展的時候建立這些可以 scale 的方案，但 Redis scale 出來比較晚，因此不少時候你們把 Redis 當成一個 Cache，如今慢慢你們把它當成存儲不那麼重要的數據的數據庫。由於它有了 scale 支持之後，你們會把更多的數據放在裏面。

而後到了 2015，嚴格來說是到 2014 年到 2015 年之間，Raft 論文發表之後，真正的 NewSQL 的理論基礎終於完成了。我以爲 NewSQL 這個理論基礎，最重要的劃時代的幾篇論文，一個是谷歌的 Spanner，是在 2013 年初發布的；再就是 Raft 是在 2014 年上半年發佈的。這幾篇至關於打下了分佈式數據庫 NewSQL 的理論基礎，這個模型是很是重要的，若是沒有模型在上面是堆不起來東西的。說到如今，你們可能對於模型仍是能夠理解的，可是對於它的實現難度很難想象。

將來的高可用必定是系統出了問題立刻能夠自動恢復，立刻能夠變成可用。好比說一個機房掛掉了，十秒鐘不能支付，十秒鐘以後系統自動恢復了變得能夠支付，即便這個數據中心不再起來我整個系統仍然是能夠支付的。Auto-Failover 的重要性就在這裏。你們不但願在睡覺的時候被一個報警給拉起來，我相信你們之後具有這樣一個能力，5 分鐘之內的報警不用理會，掛掉一個機房，又掛掉一個機房，這種連續報警纔會理。咱們內部開玩笑說，但願你們都能睡個好覺，很重要的事情就是這個。

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 上面構建的。

TiDB and TiKV

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

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 在模型上面的支持能力。

 。。。