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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）場景一

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

最佳實踐是，業(yè)務(wù)、數(shù)據(jù)具有天然水平拆分特點，如個人網(wǎng)盤，天然適合用戶id拆分，電商買家?guī)欤烊贿m合買家id拆分，電子社保卡，天然適合卡號拆分

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

2）場景二

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

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

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

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

3）場景三

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

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

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

1）場景一

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

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

2）場景二

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

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

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

3）場景三

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

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

• 使用分布式數(shù)據(jù)庫改造后，需要拆分的表，才進行分區(qū)表設(shè)計，不要“因為用了分布式，就都要分布式表”

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

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

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

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

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

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