市面上分布式關(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只支持了主鍵索引（當然不會那么慘，因為每個分片上還是走到了本地索引执俩，只是多走了幾個分片徐钠，可以用并行策略比較好的解決），這個時候你的應(yīng)用應(yīng)該怎么寫的問題奠滑，不過在核心業(yè)務(wù)場景丹皱，分庫分表恰好屏蔽掉了讓開發(fā)玩得很爽，正式上線壓力一大就出故障的問題宋税，并且方案非常成熟摊崭，另外MySQL存儲是一種非常穩(wěn)定的存在，以及運維工具杰赛、人才儲備都是相當充足的呢簸，所以你把分布式數(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)對當時的世界可能足夠了灸异，你可以用很復(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ù)庫是難度最大骨望、成熟曲線最高的一種方式硬爆，需要時間。