一些業(yè)務(wù)場(chǎng)景下，往往不需要采用分布式數(shù)據(jù)庫(kù)方案，避繁就簡(jiǎn)，有更輕量級(jí)的解決方法：

• 一些新聞、資源應(yīng)用常有寫少讀多的特點(diǎn)，建議通過部署查詢緩存和單機(jī)數(shù)據(jù)庫(kù)讀寫分離的方式來(lái)應(yīng)對(duì)，不建議升級(jí)分布式數(shù)據(jù)庫(kù)。

• 一些電商應(yīng)用會(huì)有高并發(fā)更新的特點(diǎn)，優(yōu)先建議采用業(yè)務(wù)模塊垂直拆分的方法，低成本解決業(yè)務(wù)負(fù)載高的問題。后續(xù)根據(jù)業(yè)務(wù)增長(zhǎng)情況，針對(duì)高并發(fā)的模塊單獨(dú)升級(jí)分布式數(shù)據(jù)庫(kù)。

• 一些全國(guó)級(jí)別的在線服務(wù)，就是會(huì)存儲(chǔ)海量實(shí)時(shí)數(shù)據(jù)，同時(shí)應(yīng)對(duì)高并發(fā)吞吐，這是采用分布式數(shù)據(jù)庫(kù)的典型場(chǎng)景。

• 有些應(yīng)用因?yàn)闅v史原因，以MySQL數(shù)據(jù)庫(kù)為代表，單表內(nèi)積累了上億的數(shù)據(jù)量，單表數(shù)據(jù)文件達(dá)到GB級(jí)別，性能出現(xiàn)顯著退化。此場(chǎng)景優(yōu)先建議與業(yè)務(wù)協(xié)商，減小在線數(shù)據(jù)保留時(shí)間，上線數(shù)據(jù)歸檔方案；同時(shí)要考察是否索引不夠完善，是否存在優(yōu)化空間；分布式數(shù)據(jù)庫(kù)是兜底方案。

• 對(duì)于OLAP場(chǎng)景，在不升級(jí)數(shù)據(jù)庫(kù)架構(gòu)的前提下，優(yōu)先引入流計(jì)算、預(yù)計(jì)算等大數(shù)據(jù)處理方案和產(chǎn)品，成本較低；如還不能滿足業(yè)務(wù)需求，則引入專門的OLAP數(shù)據(jù)庫(kù)。

• 如今國(guó)產(chǎn)數(shù)據(jù)庫(kù)改造是國(guó)內(nèi)各行業(yè)IT轉(zhuǎn)型的重要方向，對(duì)于之前選用傳統(tǒng)商業(yè)數(shù)據(jù)庫(kù)的客戶，最需要的是高兼容數(shù)據(jù)庫(kù)來(lái)控制改造遷移成本；而是否選用分布式，要考察客戶業(yè)務(wù)場(chǎng)景是否符合上面提到的指征。

• 數(shù)據(jù)庫(kù)容災(zāi)、異地多活的場(chǎng)景，原生分布式數(shù)據(jù)庫(kù)具有天然優(yōu)勢(shì)，可根據(jù)基礎(chǔ)資源、業(yè)務(wù)一致性要求和可用性要求，采用不同的部署架構(gòu)滿足，只需將精力集中在應(yīng)用容災(zāi)和多活的研發(fā)上。

從應(yīng)用場(chǎng)景角度看，市面上的分布式數(shù)據(jù)庫(kù)可分為OLTP、OLAP和、非機(jī)構(gòu)&專有領(lǐng)域NOSQL三個(gè)大類，這也是大多數(shù)云廠商數(shù)據(jù)庫(kù)產(chǎn)品頁(yè)面的常用分類。

1、OLTP數(shù)據(jù)庫(kù)

Mycat和PlarDB-X（之前的DRDS）系出同源，最早都是淘寶的數(shù)據(jù)庫(kù)中間件TDDL，一個(gè)開源，一個(gè)是商業(yè)產(chǎn)品。

• TiDB是非常成功的開源分布式數(shù)據(jù)庫(kù)，生態(tài)非?；钴S，有很多合作伙伴。

• OceanBase是最早螞蟻集團(tuán)研發(fā)的分布式數(shù)據(jù)庫(kù)，主要支撐了支付寶全業(yè)務(wù)，在金融行業(yè)有較多客戶成功案例，進(jìn)來(lái)已擁抱開源生態(tài)。

2、OLAP數(shù)據(jù)庫(kù)

OLAP數(shù)據(jù)庫(kù)往往要處理海量數(shù)據(jù)的復(fù)雜分析，采用MPP架構(gòu)，天然需要分布式架構(gòu)，數(shù)據(jù)分片，進(jìn)行并行計(jì)算加速。

3、非機(jī)構(gòu)化&專有領(lǐng)域NoSQL

緩存領(lǐng)域，Codis類似TP數(shù)據(jù)庫(kù)中間件的方案。

寬列數(shù)據(jù)庫(kù)（bigtable）往往用于存儲(chǔ)海量非機(jī)構(gòu)化數(shù)據(jù)，需要高寫入吞吐，天然需要分布式架構(gòu)應(yīng)對(duì)。

在時(shí)序數(shù)據(jù)庫(kù)和圖數(shù)據(jù)庫(kù)領(lǐng)域，并非全部產(chǎn)品都是分布式的，但這兩種場(chǎng)景涉及的數(shù)據(jù)量如果增長(zhǎng)較快，分布式架構(gòu)是其加分項(xiàng)。

1）場(chǎng)景一

分布式數(shù)據(jù)庫(kù)中間件使用的前提是，數(shù)據(jù)已經(jīng)進(jìn)行過充分合理的垂直拆分

最佳實(shí)踐是，業(yè)務(wù)、數(shù)據(jù)具有天然水平拆分特點(diǎn)，如個(gè)人網(wǎng)盤，天然適合用戶id拆分，電商買家?guī)?，天然適合買家id拆分，電子社?？?，天然適合卡號(hào)拆分

有高并發(fā)更新的大數(shù)據(jù)表，適合水平拆分，與他關(guān)聯(lián)的小表做廣播表，不許關(guān)聯(lián)的單表不要拆分

2）場(chǎng)景二

平滑擴(kuò)容能力，是分布式中間件的核心技術(shù)競(jìng)爭(zhēng)力，業(yè)務(wù)無(wú)感是最高境界，但很難真正做到

擴(kuò)容時(shí)可操作的數(shù)據(jù)粒度是把雙刃劍，業(yè)務(wù)靈活性和運(yùn)維便利度，不可兼得

拆分鍵級(jí)別的數(shù)據(jù)遷移與擴(kuò)容，是解決數(shù)據(jù)庫(kù)熱點(diǎn)問題的良藥

擴(kuò)容的最高境界，是底層數(shù)據(jù)節(jié)點(diǎn)和中間件計(jì)算層的自適應(yīng)彈性伸縮，目前看來(lái)，與云原生數(shù)據(jù)庫(kù)相結(jié)合是解決之道

3）場(chǎng)景三

此方案主要是對(duì)分布式數(shù)據(jù)庫(kù)中間件路由靈活性的考驗(yàn)

訪問實(shí)效性和頻率允許條件下，歸檔庫(kù)或歸檔存儲(chǔ)甚至可以是冷設(shè)備，需要時(shí)可自動(dòng)加電加載

可以為歸檔庫(kù)的OLAP訪問，配置專屬M(fèi)PP架構(gòu)的中間件proxy層，既達(dá)到并行計(jì)算加速效果，又實(shí)現(xiàn)了資源與OLTP業(yè)務(wù)隔離，避免爭(zhēng)搶

1）場(chǎng)景一

• 一大優(yōu)勢(shì)是資源自動(dòng)化管理，將新機(jī)器加入資源池，在開啟數(shù)據(jù)rebalance條件下，會(huì)自動(dòng)進(jìn)行遷移和均衡，這也是資源彈性伸縮能力的基礎(chǔ)

• 以此架構(gòu)為基礎(chǔ)，上層理論上可以兼容各種數(shù)據(jù)庫(kù)的接口，提供平滑的數(shù)據(jù)庫(kù)遷移體驗(yàn)

2）場(chǎng)景二

• 從單機(jī)房的機(jī)架位級(jí)別容災(zāi)，到兩點(diǎn)三中心的機(jī)房級(jí)別容災(zāi)，如采用傳統(tǒng)數(shù)據(jù)庫(kù)的主從復(fù)制架構(gòu)來(lái)做同步，都會(huì)遭遇一致性和可用性的兩難問題，需要數(shù)據(jù)稽核、數(shù)據(jù)修復(fù)等多重保險(xiǎn)機(jī)制，帶來(lái)復(fù)雜的應(yīng)用和數(shù)據(jù)庫(kù)開發(fā)難度

• 原生分布式數(shù)據(jù)庫(kù)通過集群化存儲(chǔ)的分布式一致性算法，確保了強(qiáng)一致性和寫入效率的同時(shí)，只要是少數(shù)派節(jié)點(diǎn)故障，也可確保數(shù)據(jù)庫(kù)服務(wù)的可用性

• 多活架構(gòu)不僅對(duì)數(shù)據(jù)庫(kù)有要求，對(duì)應(yīng)用多個(gè)分層也有流量糾錯(cuò)的嚴(yán)格要求，還需要數(shù)據(jù)庫(kù)自身具備防寫錯(cuò)能力，需要整體設(shè)計(jì)方案

3）場(chǎng)景三

• 國(guó)產(chǎn)化數(shù)據(jù)庫(kù)改造，不是必須選擇分布式方案，但分布式往往是國(guó)產(chǎn)化數(shù)據(jù)庫(kù)相對(duì)傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù)彎道超車的優(yōu)勢(shì)所在，如果選用國(guó)產(chǎn)單機(jī)數(shù)據(jù)庫(kù)，會(huì)陷入田忌賽馬的被動(dòng)局面

• 采集回放技術(shù)是這其中的關(guān)鍵一環(huán)，是遷移后數(shù)據(jù)庫(kù)功能特性和性能不退化的有力保證

• 使用分布式數(shù)據(jù)庫(kù)改造后，需要拆分的表，才進(jìn)行分區(qū)表設(shè)計(jì)，不要“因?yàn)橛昧朔植际?，就都要分布式?rdquo;

Q1：分布式最終數(shù)據(jù)一致性的常用做法和最佳實(shí)踐有哪些？

A1： 這個(gè)問題我舉一個(gè)分布式中間件的例子吧。我熟悉的一個(gè)分布式中間件，它最早實(shí)現(xiàn)決分布式事務(wù)采用的是柔性事務(wù)的方式。這個(gè)方式本質(zhì)上是由這個(gè)中間件自身來(lái)在每次執(zhí)行事務(wù)時(shí)候，記錄每條SQL的undo日志、redo日志。一旦發(fā)現(xiàn)問題之后，它自己根據(jù)情況，決策重試還是回滾，在這個(gè)過程中就存在數(shù)據(jù)中間狀態(tài).在這過程中查詢，就會(huì)查詢到數(shù)據(jù)是不一致的。但通過它的undo日志和redo日志的機(jī)制，能夠保證每筆事務(wù)的數(shù)據(jù)最終狀態(tài)是一致的。同時(shí)他們也發(fā)現(xiàn)，這個(gè)柔性事務(wù)雖然在查詢延遲、SQL吞吐上表現(xiàn)非常好，也能保證最終一致性，但對(duì)很多客戶的較苛刻的數(shù)據(jù)一致性要求，比如金融行業(yè)、電商行業(yè)交易的一些場(chǎng)景是不能很好滿足的。所以這個(gè)方案他們是作為分布式事務(wù)一種備選項(xiàng)，同時(shí)他們也實(shí)現(xiàn)了XA事務(wù)作為分布式事務(wù)的補(bǔ)充方案，并進(jìn)一步向全局邏輯時(shí)鐘事務(wù)時(shí)的方案靠攏，最后是這么做的。所以總結(jié)來(lái)說(shuō)，最終數(shù)據(jù)一致性僅能滿足一部分也業(yè)務(wù)場(chǎng)景的的需求！通用的，理想的分布式事務(wù)方案應(yīng)該是強(qiáng)一致性的。

Q2：中間件的分布式數(shù)據(jù)庫(kù)，針對(duì)業(yè)務(wù)的一些復(fù)雜多條件查詢，有一些經(jīng)驗(yàn)可以分享一下嗎？

A2： 這個(gè)問題在文章中其實(shí)有所涉及，中間件的分布式數(shù)據(jù)庫(kù)目前的一些優(yōu)秀產(chǎn)品已經(jīng)具備了全局二級(jí)索引的能力。也就是說(shuō)它可以支持有限的多維度查詢。例如，我的主數(shù)據(jù)是基于訂單id進(jìn)行拆分的，但現(xiàn)在我想安裝賣家id或買家id來(lái)進(jìn)行查詢?cè)趺崔k？我可以通過這種方式來(lái)進(jìn)行：去創(chuàng)建賣家id或買家id的二級(jí)索引，由二級(jí)索引來(lái)保存買家id或賣家id和訂單id之間的映射關(guān)系。同時(shí)為了進(jìn)一步改善性能，我還可以在我的全局二級(jí)索引里覆蓋更多字段，根據(jù)二級(jí)索引查詢時(shí)的一些要求來(lái)避免回表。通過這樣的方式來(lái)解決多維度查詢的問題。

Q3:在分布式數(shù)據(jù)庫(kù)中網(wǎng)絡(luò)分區(qū)問題遇到過嗎？

A1： 這個(gè)問題應(yīng)該是關(guān)于原生分布式數(shù)據(jù)庫(kù)的。原生分布式數(shù)據(jù)庫(kù)如果你采用之前所謂的半同步、強(qiáng)同步等一些方式，或者在基于zookeeper做一致性的分區(qū)的容錯(cuò)的情況下，其實(shí)會(huì)遇到腦裂等一些問題。但基本上現(xiàn)在的原生分布式數(shù)據(jù)庫(kù)采用的都是基于Poxos類的分布式一致性的協(xié)議來(lái)做的方案，這種方案最大的特點(diǎn)在于：只要不是多數(shù)派的節(jié)點(diǎn)出現(xiàn)故障，少數(shù)派的節(jié)點(diǎn)出現(xiàn)故障之后，多數(shù)派的節(jié)點(diǎn)就會(huì)自然而然地選主出來(lái)，快速地對(duì)外恢復(fù)服務(wù)，并且保證數(shù)據(jù)的一致性。而少數(shù)派一旦發(fā)現(xiàn)網(wǎng)絡(luò)分區(qū)，知道自己是少數(shù)派沒辦法進(jìn)行選舉之后，就會(huì)自然地對(duì)外停止服務(wù)。通過這樣的方式來(lái)避免網(wǎng)絡(luò)分區(qū)和腦裂的問題。