分布式數(shù)據(jù)庫在商業(yè)銀行設計與實踐相關的20個問題

1、 分布式數(shù)據(jù)庫在商業(yè)銀行設計與實踐相關的20個問題 前不久我們邀請行業(yè)專家分享了分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設計與實踐（點擊標題可閱讀），并與會員共同探討了在商業(yè)銀行中，分布式數(shù)據(jù)庫應用的相關問題，獲得了廣泛關注，以下是嘉賓wanglaye根據(jù)活動交流內(nèi)容總結出的重點問題和典型問題，有助于大家對分布式數(shù)據(jù)庫在商業(yè)銀行的應用進一步了解，以及弄清相關疑問、難點。供大家參考。背景大數(shù)據(jù)時代，為應對海量數(shù)據(jù)的井噴式增長和用戶需求的不斷增加，分布式數(shù)據(jù)庫應運而生。分布式數(shù)據(jù)庫將位于不同地點的多個服務器通過網(wǎng)絡互相連接，共同組成一個完整的、全局的大型數(shù)據(jù)庫，它在邏輯上集中、物理上分布。在數(shù)據(jù)存儲上

2、，分布式數(shù)據(jù)庫將數(shù)據(jù)打散存儲在不同服務器上，故而將數(shù)據(jù)庫壓力分散到不同服務器上。分布式數(shù)據(jù)庫具有以下顯著特點：高可擴展性、高并發(fā)性、高可用性。分布式數(shù)據(jù)庫在互聯(lián)網(wǎng)應用場景下已經(jīng)積累了很多成熟的技術，但相比互聯(lián)網(wǎng)企業(yè)，金融行業(yè)對分布式數(shù)據(jù)庫的要求更高，除了上文提到的高可擴展性、高并發(fā)性、高可用性之外，分布式數(shù)據(jù)庫還需要具備支持分布式事務、提供業(yè)務數(shù)據(jù)一致性、易于維護等特性，因此，金融行業(yè)需要更加完備的技術支持。面對互聯(lián)網(wǎng)業(yè)務的不斷深化以及業(yè)務量的爆發(fā)式增長，傳統(tǒng)數(shù)據(jù)庫存儲能力有限、響應時間長、服務器壓力大、擴容成本高等問題逐漸凸顯。面對交易復雜度及交易量的大幅提升，某行信息系統(tǒng)采用的傳統(tǒng)數(shù)據(jù)庫一

3、體化解決方案，在應對此類場景時遇到了明顯的性能瓶頸。該行計劃搭建基于實時交易的分布式數(shù)據(jù)庫平臺，響應國家科技金融戰(zhàn)略，開辟數(shù)據(jù)庫創(chuàng)新的新路徑；對IT系統(tǒng)而言，使用分布式數(shù)據(jù)庫可以提高性能、縮減成本、保障數(shù)據(jù)安全與高可用；對運維人員而言，分布式數(shù)據(jù)庫可以實現(xiàn)自動資源調(diào)度，提高運維效率。詳情可見：分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設計與實踐本次交流活動針對分布式數(shù)據(jù)庫在商業(yè)銀行領域的設計與實踐，基于上述實踐分享，就分布式數(shù)據(jù)庫的特點、應用場景、選型、性能、設計、實踐等方面提出了20個問題，并做了較為深入的討論和詳細的解答。一、分布式數(shù)據(jù)庫的特點、應用場景相關問題【Q1】分布式數(shù)據(jù)庫適用場景有哪些

4、？和傳統(tǒng)的數(shù)據(jù)庫有哪些不同？匿名用戶：分布式數(shù)據(jù)的使用場景，依賴于數(shù)據(jù)庫產(chǎn)品本身的特點來說的。如果非要說一些它的場景的話，哪就是兩個量大（數(shù)量量大，請求量大）共存的業(yè)務。和傳統(tǒng)數(shù)據(jù)庫的區(qū)別有幾點：1.分布式。傳統(tǒng)數(shù)據(jù)庫基本上單機版。2.能支撐更大量的數(shù)據(jù)，和請求量（或事務量）。3.因數(shù)據(jù)的分片方式不同，要結合應用場景進行選擇和應用適配。傳統(tǒng)數(shù)據(jù)庫不需要mornsky 某銀行研發(fā)工程師：互聯(lián)網(wǎng)時代，數(shù)據(jù)量、并發(fā)量劇增，傳統(tǒng)單節(jié)點數(shù)據(jù)庫方式很難適應，這就是分布式數(shù)據(jù)庫的用武之地。今后，不管是互聯(lián)網(wǎng)企業(yè)還是金融業(yè)或傳統(tǒng)企業(yè)，分布式數(shù)據(jù)庫是趨勢，或者傳統(tǒng)數(shù)據(jù)庫也將走向分布式升級改造。wanglaye某

5、商業(yè)銀行技術經(jīng)理：分布式數(shù)據(jù)庫針對的是海量數(shù)據(jù)、高并發(fā)交易的應用場景。傳統(tǒng)事務型業(yè)務場景在選擇數(shù)據(jù)庫時，也要考慮分布式數(shù)據(jù)庫是否支持分布式事務?！綫2】TIDB 相對比一體機區(qū)別？tshqin PingCAP 數(shù)據(jù)庫管理員：具體是那種一體機呢？大機，AS/400，Teradata，Netezza，Exadata，HANA？TiDB 一般使用場景是數(shù)據(jù)量較大的 OLTP 系統(tǒng)，也可以混合輕量 OLAP 運算。【Q3】分布式數(shù)據(jù)庫有沒有安裝簡易的簡易學習版或者單機版，用于學習普及培訓?gaolyang 某商業(yè)銀行 技術經(jīng)理：建議到pingcap官網(wǎng)上看看，上面有很詳細的學習文檔，/docs-cn/

6、。MrSylar 某金融公司 數(shù)據(jù)庫管理員：有木有建議學習版或者單機版，我不是很確認。但個人感覺，所有的數(shù)據(jù)庫安裝基本都不會是問題，無非是個熟悉的過程，你更多需要的是個成功的安裝文檔，so 多加幾個相關的群，你會發(fā)現(xiàn)一大堆。冰玉 北京瑞尼爾 數(shù)據(jù)庫開發(fā)工程師：分布式是在多臺服務器的基礎上的，單機的可以是分布式的單個節(jié)點獨立運行。他的難點就是多臺機器協(xié)作作業(yè)，單機可以運行但是沒有什么意義?？梢院唵吸c，在兩個虛擬機上安裝。分布式并不是很高深，內(nèi)部原理復雜，通常配置和使用并不是很麻煩。劉誠杰 平安城科 數(shù)據(jù)庫管理員：mongodb的sharding，可以使用mtools工具快速安裝單機的學習版（測試

7、版）?！綫4】Db2 dpf數(shù)據(jù)庫屬于分布式數(shù)據(jù)庫嗎？有沒有正在使用的，性能、可靠性如何？wanglaye某商業(yè)銀行技術經(jīng)理：Db2是傳統(tǒng)數(shù)據(jù)庫，與分布式數(shù)據(jù)庫還存在很大區(qū)別。tshqin PingCAP 數(shù)據(jù)庫管理員：shared nothing 的 MPP 在廣義上也屬于分布式架構，用于重型 OLAP 系統(tǒng)，如經(jīng)營分析，財務報表，反欺詐，決策支持等系統(tǒng)。在 MPP 數(shù)據(jù)庫中，一張表的數(shù)據(jù)分布在多個分區(qū)上，可靠性隨分區(qū)數(shù)量增加線性下降，可以通過對分區(qū)進行多副本復制提高可用性。Join 性能是 MPP 的核心競爭力，因此被大規(guī)模用于 OLAP 系統(tǒng)中，而 OLAP 對于可用性要求不太高的特點也

8、一定程度掩蓋了 MPP 的缺點。此種架構不作 OLTP 系統(tǒng)數(shù)據(jù)庫使用。馮萬里 IBM 數(shù)據(jù)庫架構師：確切說dpf是屬于閹割了高可用功能的分布式數(shù)據(jù)庫。因為dpf雖然有多個節(jié)點，每個節(jié)點又有多個分區(qū)，但是宕掉任何一個節(jié)點，數(shù)據(jù)庫功能都無法正常使用，和平常大眾所認知的分布式數(shù)據(jù)庫還有一些差別?！綫5】HBASE分布式數(shù)據(jù)庫特點？yinxin 某集團公司 項目經(jīng)理：Hbase的優(yōu)點：1 列的可以動態(tài)增加，并且列為空就不存儲數(shù)據(jù),節(jié)省存儲空間.2 Hbase自動切分數(shù)據(jù)，使得數(shù)據(jù)存儲自動具有水平scalability.3 Hbase可以提供高并發(fā)讀寫操作的支持Hbase的缺點：1 不能支持條件查詢，

9、只支持按照Row key來查詢.2 暫時不能支持Master server的故障切換,當Master宕機后,整個存儲系統(tǒng)就會掛掉.其他：1.數(shù)據(jù)類型，HBase只有簡單的字符類型，所有的類型都是交由用戶自己處理，它只保存字符串。而關系數(shù)據(jù)庫有豐富的類型和存儲方式；2.數(shù)據(jù)操作：HBase只有很簡單的插入、查詢、刪除、清空等操作，表和表之間是分離的，沒有復雜的表和表之間的關系，而傳統(tǒng)數(shù)據(jù)庫通常有各式各樣的函數(shù)和連接操作；3.存儲模式：HBase是基于列存儲的，每個列族都由幾個文件保存，不同的列族的文件時分離的。而傳統(tǒng)的關系型數(shù)據(jù)庫是基于表格結構和行模式保存的；4.數(shù)據(jù)維護，HBase的更新操作不

10、應該叫更新，它實際上是插入了新的數(shù)據(jù)，而傳統(tǒng)數(shù)據(jù)庫是替換修改；5.可伸縮性，Hbase這類分布式數(shù)據(jù)庫就是為了這個目的而開發(fā)出來的，所以它能夠輕松增加或減少硬件的數(shù)量，并且對錯誤的兼容性比較高。而傳統(tǒng)數(shù)據(jù)庫通常需要增加中間層才能實現(xiàn)類似的功能?！綫6】mycat主要的應用場景是什么呢？是不是主要和mysql進行結合？喂小飽me9 chinapay 數(shù)據(jù)庫運維工程師：mycat是基于mysql的，目前正好有測這個，我的主要目的是為了方便將SQL語句翻譯成MONGODB語句，應用程序通過連接mycat去查詢后端的MONGODB，mycat也可以作為一個庫集成工具，對于用戶來說，只要查詢mycat，

11、就可以查到mycat后端的多個庫。TonyWang 系統(tǒng)工程師：建議看官網(wǎng)介紹 http:/www.mycat.io/【Q7】MySQL分布式有什么成熟的方案（除了MyCAT）？TonyWang系統(tǒng)工程師：MyCat 是MySQL分布式的一種實現(xiàn)方式，以數(shù)據(jù)庫代理方式其他方式也可以考慮，下圖是京東的網(wǎng)址：http:/shardingsphere.io/document/current/cn/overview/二、分布式數(shù)據(jù)庫的選型相關問題【Q1】主流的分布式數(shù)據(jù)庫有哪些？login 網(wǎng)絡架構師：市面上的分布式數(shù)據(jù)庫有Tidb、巨杉、OB、TDSQL等。韓成亮 某金融 數(shù)據(jù)庫架構師：補充下GPD

12、B/MariaDB ColumnStore/products/technology/columnstore【Q2】選擇分布式數(shù)據(jù)庫對于銀行自身的意義？有哪些好處？wanglaye某商業(yè)銀行技術經(jīng)理：隨著國家對信息系統(tǒng)安全可控的要求不斷提高，銀行業(yè)對于自身的技術路線選擇也應自主可控。近年來，商業(yè)銀行紛紛加大對分布式數(shù)據(jù)庫的投入，大部分銀行仍處于探索階段，少數(shù)銀行將分布式數(shù)據(jù)庫技術應用于非業(yè)務交易系統(tǒng)上。因此，我行計劃搭建基于實時交易的分布式數(shù)據(jù)庫平臺，以開辟數(shù)據(jù)庫創(chuàng)新的新路徑。此外，對IT系統(tǒng)而言，分布式數(shù)據(jù)庫可提高性能、縮減成本、保障數(shù)據(jù)安全與高可用。對運維人員而言，分布式數(shù)據(jù)庫可以進行一定程

13、度的自動資源調(diào)度，提高運維效率。韓成亮 某金融 數(shù)據(jù)庫架構師：首先需要明確一件事情，銀行也是需要分布式數(shù)據(jù)庫的。目前的數(shù)據(jù)庫系統(tǒng)架構，理論上當然是沒問題的，但是隨著未來業(yè)務場景的變化，會造成諸如業(yè)務量的急速上升，同時周邊產(chǎn)品的蝴蝶效應，還有一些互聯(lián)網(wǎng)業(yè)務的發(fā)展，不可避免的會造成高并發(fā)，高數(shù)據(jù)量，高可用性的相關要求，自然而然，分布式數(shù)據(jù)庫的需求就應用而生，當然，這兩者是有一定的關聯(lián)性，并不是一蹴而就的，對于其他行業(yè)而言，也是一樣的道理。對于銀行而言，目前的架構容災無可厚非，由于銀行行業(yè)的特殊性，一般話而言會有多個災備中心，在大部分的情況下，災備中心的機器會存在一定程度的資源浪費，乃至可以說是空置

14、，還需要經(jīng)常的進行切換，保證災備中心的可用性，還有就說機器的規(guī)模，基本上會要求1：1 ，無論是從硬件成本還是人力成本都是很大的開支。從某種角度上而言，銀行可能比其他任何行業(yè)都急需分布式數(shù)據(jù)庫的需求。分布式數(shù)據(jù)庫的好處，簡單點說就是 成本低，易維護，易擴展，可以有更多的成本投入到業(yè)務中去。tshqin PingCAP 數(shù)據(jù)庫管理員：傳統(tǒng)架構中的核心數(shù)據(jù)庫如大機，AS/400，Power + Oracle Rac/DB2 PureScale 都已經(jīng)或?qū)⒚媾R一個非常核心的挑戰(zhàn) - OLTP 系統(tǒng)數(shù)據(jù)量超過了架構所能承載的極限，離線部分如日終處理，季度結息等也耗時越來越久。分布式數(shù)據(jù)庫的計算+存儲 s

15、cale-out 能力突破了現(xiàn)有架構的容量限制?！綫3】當前金融環(huán)境下分布數(shù)據(jù)庫選型？目前分布式數(shù)據(jù)庫各式各樣，要想選擇一個靠譜的分布式數(shù)據(jù)庫是特別的難。特別對于金融行業(yè)，對數(shù)據(jù)的一致性、可用性要求這么高。p14159 數(shù)據(jù)庫管理員：目前很多金融公司都開始使用多云的環(huán)境，對應的數(shù)據(jù)庫也開始向著分布式發(fā)展，OLTP OLAP的界限不再明顯。 市場上有很多類似的產(chǎn)品，商業(yè)的如阿里的DRDS、亞馬遜的Aurora等，開源的如CockroachDB 、TiDB 、 巨杉、 RadonDB 等。更多的選擇，更多的學習成本，給技術人員帶來了更多的挑戰(zhàn)。在分布式數(shù)據(jù)庫的選擇上，大家重點要考慮哪些因素？個人認

16、為有如下幾點：1 大廠/社區(qū)的支持2 龐大的用戶規(guī)模，豐富的生產(chǎn)使用案例3 開發(fā)團隊更重視用戶的聲音，能夠及時調(diào)整設計思路。4 對原生的SQL完全支持5 完整的生態(tài)，如備份遷移工具，優(yōu)化分析報告、監(jiān)控與自動化管理等gaolyang 某商業(yè)銀行技術經(jīng)理：還有一點很重要，公司的技術支持態(tài)度及能力。wuwenpin 軟件開發(fā)工程師：自身的技術力量更重要。匿名用戶：我個人覺得從幾個地方去看：1.產(chǎn)品成熟度。數(shù)據(jù)庫是個非常重要的系統(tǒng)，對系統(tǒng)的穩(wěn)定性要求非常好，產(chǎn)品成熟度高代表著穩(wěn)定性會好一些。2.使用廣泛。使用廣泛也是為了穩(wěn)定性，同時遇到問題，有響應的社群交流。3.技術實力。公司是否具有很高的技術實力和

17、知名度。4.針對這些產(chǎn)品結合自己的金融場景來選擇，其實上面的不是都適合金融的OLTP場景。5.成本。這里包括購買成本，以及維護成本，這個需要自己去測試一下。【Q4】選擇分布式數(shù)據(jù)庫所注重的數(shù)據(jù)庫特性有哪些？匿名用戶：我個人覺得有幾點需要關注：1.是OLTP還是OLAP？2.在具體的場景下性能如何？3.數(shù)據(jù)分布的策略是什么？4.增刪節(jié)點是否比較容易？5.后續(xù)在使用過程中如果遇到問題，它支持是否給力？【Q5】貴行對于分布式數(shù)據(jù)庫的技術評價項有哪些方面？wanglaye某商業(yè)銀行技術經(jīng)理：主要有以下幾個關鍵評價指標：可靠性和高可用性，靈活擴展能力，分布式查詢支持性，兼容性，基礎運維友好性。三、分布式

18、數(shù)據(jù)庫設計、實踐、性能相關問題【Q1】傳統(tǒng)數(shù)據(jù)庫如果要改造成分布式數(shù)據(jù)庫，有哪些技術難點？韓成亮 某金融 數(shù)據(jù)庫架構師：個人覺得主要是思維模式的轉(zhuǎn)變，畢竟分布式數(shù)據(jù)庫就目前而言，在事務而言，采用的分布式事務，還有就是分布式數(shù)據(jù)庫主要有調(diào)度節(jié)點，計算節(jié)點和存儲節(jié)點構成，這個跟傳統(tǒng)的其實是個很大的差別，對于問題的排查可能需要更加準確的認知，還有一些分布式數(shù)據(jù)庫的特性，分布式數(shù)據(jù)庫的使用習慣，跟傳統(tǒng)的有很大差別，比方說一件擴容，彈性擴展，在線遷移，還有就是高可用等，其次是傳統(tǒng)意義上的備份方式就不是很實用了。至于傳統(tǒng)數(shù)據(jù)庫的改造，說到底就是業(yè)務的改變，簡單點而言，無論是傳統(tǒng)數(shù)據(jù)庫還是分布式數(shù)據(jù)庫說到底

19、的本質(zhì)上而言是存儲數(shù)據(jù)，并進行相應的業(yè)務邏輯處理，存儲數(shù)據(jù)庫大體是一致的，對于業(yè)務的處理部分就會牽扯到事務了，乃至于性能響應了，這部分的難點不言而喻，事務的一致性跟性能的可用性就是一個取舍，當然也可以使用事務的最終一致性來解決，而這個也是常規(guī)的分布式數(shù)據(jù)庫所推薦的方案。gaolyang 某商業(yè)銀行技術經(jīng)理：首先從業(yè)務系統(tǒng)角度來說，該系統(tǒng)所使用的數(shù)據(jù)庫對象構成方面，最好只有簡單的SQL語句，而無存儲過程等傳統(tǒng)數(shù)據(jù)庫中的復雜對象，也就是數(shù)據(jù)遷移成本；其次，對于所創(chuàng)建的分布式數(shù)據(jù)庫集群，由于集群有一定的服務器規(guī)模，所以要平衡硬件成本問題；最后我認為，業(yè)務系統(tǒng)的類型除了應滿足高并發(fā)等OLTP數(shù)據(jù)庫的特

20、性之外，還有海量數(shù)據(jù)存儲的需要?！綫2】貴行做的分布式數(shù)據(jù)庫的多活如何保證網(wǎng)絡的延時？wanglaye 某商業(yè)銀行技術經(jīng)理：集群內(nèi)部使用萬兆網(wǎng)絡通訊最佳，多數(shù)據(jù)中心之間使用裸光纖+波分設備是最佳選擇，如果是異地，在條件允許的情況下，用光纖最佳，但要考慮高昂的成本。最好是從架構層面設計多活，從業(yè)務層面考慮異地網(wǎng)絡的延時。chrislay UBI系統(tǒng)架構師：多數(shù)據(jù)庫中心，租用運營商的帶寬，一般是波分設備，有的是拉裸纖，成本就高了，還有就是業(yè)務架構上的優(yōu)化?！綫3】單數(shù)據(jù)中心，多 TiKV 進程終止、TiKV 服務器宕機、TiDB 服務器宕機、PD 服務器宕機，集群是否仍然可以對外服務？匿名用戶：單

21、數(shù)據(jù)中心下，出現(xiàn)一定程度（每個產(chǎn)品有一定的最大宕機數(shù)）宕機，集群是可以對外提供服務的。如果是多IDC下，目前很多分布式數(shù)據(jù)庫是做不到的，除非考慮IDC之間做專線。wanglaye 某商業(yè)銀行技術經(jīng)理：這個要考慮整個集群的架構設計。TiKV 是一個集群，通過 Raft 協(xié)議保持數(shù)據(jù)一致性，并通過 PD 做負載均衡調(diào)度。單個TiKV節(jié)點失效時，會影響這個節(jié)點上存儲的所有Region。對于 Region 中的Leader 結點，會中斷服務，等待其他TiKV上的Region重新選舉Leader，待Leader選出了可繼續(xù)對外提供服務，這個過程非常短；對于Region 中的Follower節(jié)點，不會影響

22、服務。TiDB 是無狀態(tài)的，通過前端的F5對外提供服務。當單個TiDB實例失效時，僅僅會影響正在這個實例上進行的會話，從應用的角度看，會出現(xiàn)單次請求失敗的情況，應用重新連接至其他TiDB實例后即可繼續(xù)獲得服務。單個TiDB實例失效后，可以重啟這個實例或者部署一個新的實例。PD 是一個集群，通過 Raft 協(xié)議保持數(shù)據(jù)的一致性。單個實例失效時，如果不是leader，那么服務完全不受影響；如果是leader，那么PD集群會重新選出新的leader，自動恢復服務。在實際測試和應用過程中，單數(shù)據(jù)中心，TiKV 服務不可用、TiKV 主機故障、TiDB 主機故障、PD 主機故障，數(shù)據(jù)庫均能正常提供服務。

23、【Q4】集群中單臺TiKV出現(xiàn)故障，如tikv進程終止、TiKV 主機萬兆網(wǎng)卡斷開、TiKV 主機服務器宕機，集群是否仍然可以對外服務？wanglaye某商業(yè)銀行技術經(jīng)理：只要集群中剩余可用副本數(shù)仍占大多數(shù)，集群就可以對外服務。TiKV 進程終止，集群對外服務正常TiKV。進程恢復后，數(shù)據(jù)同步正常，該TiKV 恢復正常狀態(tài)。單臺 TiKV 網(wǎng)絡故障，數(shù)據(jù)庫正常提供服務。 網(wǎng)絡恢復后，數(shù)據(jù)同步正常，該 TiKV 恢復正常狀態(tài)。單臺 TiKV 主機故障，數(shù)據(jù)庫正常提供服務。 主機恢復后，數(shù)據(jù)同步正常，該 TiKV 恢復正常狀態(tài)。tshqin PingCAP 數(shù)據(jù)庫管理員：在部署集群的時候可以為集群

24、中的 tikv 添加 label 信息，PD 會根據(jù) label 信息進行副本調(diào)度，根據(jù)所配置的 label 級別的不同，可以避免將同一個 region 的兩個 replica 調(diào)度到：同一臺服務器的兩個 tikv 實例上同一個機架的幾個 tikv 實例上同一個機房的幾個 tikv 實例上據(jù)此可以實現(xiàn)服務器級/機架級/機房級的容災，因為集群中還存活大多數(shù)的副本就有能力對外提供服務。詳情參考官方手冊：/docs/op-guide/location-awareness/【Q5】OLTP型分布式數(shù)據(jù)庫跨節(jié)點事務性能問題？金融銀行傳統(tǒng)業(yè)務采用分布式數(shù)據(jù)庫的話，業(yè)務場景復雜，例如對賬戶表的拆分，轉(zhuǎn)賬交易

25、的話可能會導致大量的分布式事務，影響整體數(shù)據(jù)庫性能，或者無法發(fā)揮分布式數(shù)據(jù)庫的優(yōu)勢，針對這個問題，有沒有比較理想的解決方案？劉誠杰 平安城科數(shù)據(jù)庫管理員：CAP就占有技術本身就無法兼得，在銀行場景只能犧牲速度，保證事務執(zhí)行。除了核心的資金場景，少用事務可以更合理使用分布式數(shù)據(jù)庫。韓成亮 某金融數(shù)據(jù)庫架構師：針對這個問題，首先我們需要了解事務的一致性，分布式數(shù)據(jù)庫不可避免的或多或少存在這樣的問題，簡單點而言，我們有些時候并不需要保證單個事務的一致性，我們可能通過最終一致性來解決，而這個也是分布式數(shù)據(jù)庫設計的一個因素，因為往往有些時候可用性和一致性很難平衡，這就有了保證最終一致性的各種措施比如消息隊列，全局事務表，二階段提交，三階段提交等?！綫6】分布式數(shù)據(jù)庫在運維過程中的坑有哪些？陽嗨超 某平臺架構部高級技術經(jīng)理IT顧問：所謂的坑是需要看具體的某一個產(chǎn)品的。分布式數(shù)據(jù)庫運維中，整體來說有幾個地方的挑戰(zhàn)：1. 是運維的復雜度會提升不少。譬如：異常故障的處理等。 2.備份和恢復會復雜一些。這些的恢復是指產(chǎn)生邏輯