另外一個值得一提的是PostgreSQL XC這個項目，其整體的架構(gòu)有點像早期版本的OceanBase，由一個中央節(jié)點來處理協(xié)調(diào)分布式事務(wù)，數(shù)據(jù)分散在各個存儲節(jié)點上，應(yīng)該是目前PG 社區(qū)最好的分布式擴展方案，不少人在基于這個項目做自己的系統(tǒng)。
3、NewSQL的發(fā)展
2012~2013年Google 相繼發(fā)表了Spanner和F1兩套系統(tǒng)的論文，讓業(yè)界第一次看到了關(guān)系模型和NoSQL的擴展性在一個大規(guī)模生產(chǎn)系統(tǒng)上融合的可能性。 Spanner 通過使用硬件設(shè)備（GPS時鐘+原子鐘）巧妙地解決時鐘同步的問題，而在分布式系統(tǒng)里，時鐘正是最讓人頭痛的問題。Spanner的強大之處在于即使兩個數(shù)據(jù)中心隔得非常遠(yuǎn)，也能保證通過TrueTime API獲取的時間誤差在一個很小的范圍內(nèi)（10ms），并且不需要通訊。Spanner的底層仍然基于分布式文件系統(tǒng)，不過論文里也說是可以未來優(yōu)化的點。
Google的內(nèi)部的數(shù)據(jù)庫存儲業(yè)務(wù)，大多是3~5副本，重要的數(shù)據(jù)需要7副本，且這些副本遍布全球各大洲的數(shù)據(jù)中心，由于普遍使用了Paxos，延遲是可以縮短到一個可以接受的范圍(寫入延遲100ms以上)，另外由Paxos帶來的Auto-Failover能力，更是讓整個集群即使數(shù)據(jù)中心癱瘓，業(yè)務(wù)層都是透明無感知的。F1是構(gòu)建在Spanner之上，對外提供了SQL接口，F(xiàn)1是一個分布式MPP SQL層，其本身并不存儲數(shù)據(jù)，而是將客戶端的SQL翻譯成對KV的操作，調(diào)用Spanner來完成請求。
Spanner和F1的出現(xiàn)標(biāo)志著第一個NewSQL在生產(chǎn)環(huán)境中提供服務(wù)，將下面幾個功能在一套系統(tǒng)中提供：
SQL支持
ACID事務(wù)
水平擴展
Auto Failover
多機房異地容災(zāi)
正因為具備如此多的誘人特性，在Google內(nèi)部，大量的業(yè)務(wù)已經(jīng)從原來的 BigTable切換到Spanner之上。相信這對業(yè)界的思路會有巨大的影響，就像當(dāng)年的Hadoop一樣，Google的基礎(chǔ)軟件的技術(shù)趨勢是走在社區(qū)前面的。
Spanner/F1論文引起了社區(qū)的廣泛的關(guān)注，很快開始出現(xiàn)了追隨者。第一個團隊是CockroachLabs做的CockroachDB。CockroachDB的設(shè)計和Spanner很像，但是沒有選擇TrueTime API ，而是使用HLC（Hybrid logical clock），也就是NTP +邏輯時鐘來代替TrueTime時間戳，另外CockroachDB選用Raft做數(shù)據(jù)復(fù)制協(xié)議，底層存儲落地在RocksDB中，對外的接口選擇了PG協(xié)議。
CockroachDB的技術(shù)選型比較激進，比如依賴了HLC來做事務(wù)，時間戳的精確度并沒有辦法做到10ms內(nèi)的延遲，所以Commit Wait需要用戶自己指定，其選擇取決于用戶的NTP服務(wù)時鐘誤差，這點對于用戶來說非常不友好。當(dāng)然 CockroachDB的這些技術(shù)選擇也帶來了很好的易用性，所有邏輯都在一個組件中，部署非常簡單，這個是非常大的優(yōu)點。
另一個追隨者就是我們做的TiDB。這個項目已經(jīng)開發(fā)了兩年時間，當(dāng)然在開始動手前我們也準(zhǔn)備了很長時間。接下來我會介紹一下這個項目。
二、TiDB的架構(gòu)和最近進展
TiDB本質(zhì)上是一個更加正統(tǒng)的Spanner和F1實現(xiàn)，并不CockroachDB那樣選擇將SQL和KV融合，而是像Spanner和F1一樣選擇分離。
這樣分層的思想也是貫穿整個TiDB項目始終的，對于測試，滾動升級以及各層的復(fù)雜度控制會比較有優(yōu)勢，另外TiDB選擇了MySQL協(xié)議和語法的兼容，MySQL社區(qū)的ORM框架、運維工具，直接可以應(yīng)用在TiDB上，另外和 Spanner一樣，TiDB是一個無狀態(tài)的MPP SQL Layer，整個系統(tǒng)的底層是依賴 TiKV 來提供分布式存儲和分布式事務(wù)的支持，TiKV的分布式事務(wù)模型采用的是Google Percolator的模型，但是在此之上做了很多優(yōu)化，Percolator的優(yōu)點是去中心化程度非常高，整個繼續(xù)不需要一個獨立的事務(wù)管理模塊，事務(wù)提交狀態(tài)這些信息其實是均勻分散在系統(tǒng)的各個key的meta中，整個模型唯一依賴的是一個授時服務(wù)器，在我們的系統(tǒng)上，極限情況這個授時服務(wù)器每秒能分配 400w以上個單調(diào)遞增的時間戳，大多數(shù)情況基本夠用了（畢竟有Google量級的場景并不多見），同時在TiKV中，這個授時服務(wù)本身是高可用的，也不存在單點故障的問題。
上面是TiKV的架構(gòu)圖。TiKV和CockroachDB一樣也是選擇了Raft作為整個數(shù)據(jù)庫的基礎(chǔ)，不一樣的是，TiKV整體采用Rust語言開發(fā)，作為一個沒有GC和 Runtime的語言，在性能上可以挖掘的潛力會更大。不同TiKV實例上的多個副本一起構(gòu)成了一個Raft Group，PD負(fù)責(zé)對副本的位置進行調(diào)度，通過配置調(diào)度策略，可以保證一個Raft Group的多個副本不會保存在同一臺機器/機架/機房中。
除了核心的TiDB、TiKV之外，我們還提供了不少易用的工具，便于用戶做數(shù)據(jù)遷移和備份。比如我們提供的Syncer，不但能將單個MySQL實例中的數(shù)據(jù)同步到TiDB，還能將多個MySQL實例中的數(shù)據(jù)匯總到一個TiDB集群中，甚至是將已經(jīng)分庫分表的數(shù)據(jù)再合庫合表。這樣數(shù)據(jù)的同步方式更加靈活好用。