市面上分布式關(guān)系型數(shù)據(jù)庫目前越來越多，大家的主要目標就是解決關(guān)系型數(shù)據(jù)庫擴展性問題，但是流派主要分3波，分庫分表加mysql存儲，Spanner路線，Aurora路線。

走分庫分表加mysql存儲路線的，開源產(chǎn)品中有cobar,mycat,sharding-jdbc等，閉源能使用到的產(chǎn)品包括阿里云上的DRDS(TDDL)、騰訊云上的DCDB(TDSQL)等，這條路線最近被另外兩條路線抨擊比較多，因為站在某些業(yè)務(wù)場景和規(guī)模上(中小場景和規(guī)模)，分庫分表確實對業(yè)務(wù)要求比較高，存在比較繁重的業(yè)務(wù)改造，核心問題在于這條路線暴露了拆分條件，需要讓用戶根據(jù)業(yè)務(wù)特性來判斷，一下子把產(chǎn)品做成了一個架構(gòu)設(shè)計，實際上拆分條件就是數(shù)據(jù)聚簇的依據(jù)，類似用單機關(guān)系型數(shù)據(jù)庫也會糾結(jié)選擇哪個唯一字段做主鍵一樣，無非讓查詢相對二級索引少走一次btree檢索，但是分庫分表或者分布式數(shù)據(jù)庫領(lǐng)域，維護二級索引一致性無論是強一致還是最終一致都是一個比較痛苦的事情，因為索引和聚簇的數(shù)據(jù)可能不在一個節(jié)點上，這樣就跨了一次網(wǎng)絡(luò)，不確定性大幅度上升(MySQL單機聚簇數(shù)據(jù)和索引很少不一致，但是主備數(shù)據(jù)不一致概率大很多，大部分是因為數(shù)據(jù)同步中斷)，但是二級索引還是有必要存在的，一些產(chǎn)品也提供了這種能力支撐，但是不能濫用。某種意義上來說，把應(yīng)用改成使用分庫分表的數(shù)據(jù)庫解決方案時，就如同單機MySQL只支持了主鍵索引（當(dāng)然不會那么慘，因為每個分片上還是走到了本地索引，只是多走了幾個分片，可以用并行策略比較好的解決），這個時候你的應(yīng)用應(yīng)該怎么寫的問題，不過在核心業(yè)務(wù)場景，分庫分表恰好屏蔽掉了讓開發(fā)玩得很爽，正式上線壓力一大就出故障的問題，并且方案非常成熟，另外MySQL存儲是一種非常穩(wěn)定的存在，以及運維工具、人才儲備都是相當(dāng)充足的，所以你把分布式數(shù)據(jù)庫比作一位姑娘，Spanner路線和Aurora路線的產(chǎn)品就像一個讓你浴火焚身的熱辣妹子，分庫分表加mysql路線就如同一個其貌不揚，但是能夠踏踏實實每天把飯菜做好給你吃的居家女孩。

走Spanner路線，開源產(chǎn)品中有最近比較火的TiDB,以及google Colossus團隊出來的人打造的CockroachDB，閉源能使用到的就是Google Cloud上的Spanner產(chǎn)品本尊，阿里云上的Oceanbase也走的這條路線，雖然一直掛在阿里云上，但是一直不見客。這條路線實際上和分庫分表加MySQL唯一區(qū)別就在于事務(wù)處理。關(guān)系型數(shù)據(jù)庫里面，最核心就是事務(wù)，所有的索引、唯一約束、主鍵約束、外鍵約束、DDL等都依賴于事務(wù)。分布式數(shù)據(jù)庫這個領(lǐng)域，事務(wù)核心在于可見性。一致性或者原子性可以通過log實現(xiàn)，但是可見性只有兩條路：分布式鎖或者分布式MVCC，騰訊的DCDB底下基于MariaDB經(jīng)過艱難困苦的改造，勉強基于XA實現(xiàn)了分布式事務(wù)(騰訊之前放出過來一篇文章，隨后馬上被刪除了)，但代價非常巨大，性能不行，而基于原生MySQL，XA壓根是一個雞肋，兩個重大問題長期沒有解決(半開事務(wù)沒有掛起能力，主備同步問題），直到最近5.7.X才得到解決，效果未知，另外分布式死鎖是這個領(lǐng)域里比較惡心的問題。如果想基于分布式MVCC實現(xiàn)分布式可見性，一個是MySQL并沒有暴露或者很難暴露版本，另外如果想要基于MySQL上做一層MVCC，數(shù)據(jù)實時合并的噩夢讓人恐懼，所以這條路線產(chǎn)品的存儲必然是一個新的東西，需要時間和場景歷練，沒個5-6年下不來。

走Aurora路線的，開源據(jù)了解應(yīng)該沒有，閉源能夠使用到的只有AWS上的Aurora,阿里云上的PolarDB也走這個路線，但是目前還在內(nèi)測，具體未知，從某種意義上來說,Oracle RAC是這類數(shù)據(jù)庫的祖先，歸并到這類也無可厚非，這條路線實際上我個人覺得是從大部分用戶訴求去考慮了，就是大部分用戶QPS打不滿單機數(shù)據(jù)庫，但是數(shù)據(jù)把磁盤給撐爆了?？赡苡腥讼胍粋€數(shù)據(jù)庫機器下掛很多個盤不就解決問題了，但是還是會碰到數(shù)據(jù)庫備份、克隆、DDL因為大數(shù)據(jù)文件的搬遷導(dǎo)致的延遲和不確定性，所以解決方案就從存儲這層下手，分布式用戶態(tài)文件系統(tǒng)、RDMA等措施改造底層存儲，解決數(shù)據(jù)傳輸帶寬限制、數(shù)據(jù)讀寫損耗、數(shù)據(jù)備份緩慢等問題，但是上層MySQL還是MySQL,全兼容，存儲又能做得很大。不過同時因為分布式能力的缺失，事務(wù)讀寫只能單點，只能靠強力的機器堆，滿足大部分用戶的數(shù)據(jù)事務(wù)讀寫要求，并且RDMA在容災(zāi)層面存在問題，需要靠管控快速切換或者類似paxos解決問題。AWS在國內(nèi)不給力，不過如果有機會在Aurora上實際跑跑業(yè)務(wù)可能是真正了解這種架構(gòu)優(yōu)缺點的唯一方法，因為我在google上找Aurora的缺點，確實沒有找到，要么實在太好了，要么就是用得人還不多。

使用關(guān)系型數(shù)據(jù)庫是一個控制欲望的過程，20年前，關(guān)系型數(shù)據(jù)庫應(yīng)對當(dāng)時的世界可能足夠了，你可以用很復(fù)雜的關(guān)系模型，因為數(shù)據(jù)量和訪問量就那么大，但是現(xiàn)在時代發(fā)展了，很多時候我們沒有意識到以前實現(xiàn)的關(guān)系模型可能并不適用于現(xiàn)在的業(yè)務(wù)場景，說得難聽點，就是糟粕了。這個領(lǐng)域是在不斷往前看，也許以前在做分庫分表的產(chǎn)品，會推出新存儲的強一致分布式數(shù)據(jù)庫，做Aurora類型數(shù)據(jù)庫的加一層共享內(nèi)存實現(xiàn)事務(wù)讀寫的強一致性，而做spanner路線數(shù)據(jù)庫是難度最大、成熟曲線最高的一種方式，需要時間。