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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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