商業銀行如何進行分散式資料庫選型思考

行業背景

---

1、銀行業為什麼需要採用分散式資料庫？

背景及現狀：

在傳統資料大集中的環境下，銀行核心系統很容易發生故障，而且一旦發生故障，影響面將特別廣，帶來很大的輿論壓力和監管壓力，歷史上大型商業銀行核心系統故障的例子不在少數。而且傳統的集中 式架構不易擴充套件，各模組間高度耦合，最終造成核心繫統體量太過龐大、業務太過繁重。

分散式資料庫優勢：

企業採用分散式資料庫，我覺得有多方面原因：

① 傳統的資料庫是否已經難以承受當前的負載

② 是否需要規避全域性風險

分散式資料庫天然可擴充套件的架構正好解決了上述問題。分散式資料庫專案既可以避免將雞蛋放在一個籃子裡，又可以水平擴充套件，提高吞吐量。但是目前分散式資料庫總體還不是很成熟，因此需要全面的評估測試後才能決定。

 

2、如何評估銀行分散式資料庫專案的整體成本？

成本可以分為開發測試成本、資料庫的軟硬體成本、運營維護成本等。開發測試成本主要是開發該專案的人力成本，這個因專案而異。分散式資料庫的硬體成本主要包括PC伺服器加本地SSD盤，軟體成本因廠商而異。大致如下：

3、銀行行業中用分散式資料庫的多嗎？現在是什麼形勢？

目前銀行業對分散式資料的使用還是持一個比較謹慎的態度，但是各大銀行都在進行分散式資料庫的探索，包括選型測試等。目前有些銀行已經在核心繫統上線了開源的分散式資料庫，其他還有些銀行在和一些企業進行聯合創新研發，我行目前也在積極探索中。

 

4、在銀行業中，分散式資料庫的供應商有哪些？

目前市面上分散式資料庫產品很多，比較流行的主要有pingcap的tidb，巨杉的sequoiaDB，阿里的OceanBase、polardb，騰訊的Tbase、tdsql，華為的gaussdb，亞信的antdb等。各個產品大致特點如下：

 

方案設計

---

5、在分散式資料庫專案中，如何進行技術路線的選擇？

分散式一般分為三條技術路線：分散式訪問客戶端、分散式中介軟體模式、分散式資料庫模式。其中分散式訪問客戶端對應用侵入性大，改造難度很高；分散式中介軟體則類似mycat等產品，在資料庫和應用間架一層proxy，這種方案無法支援分散式事務、也無法支援跨庫關聯，分散式資料庫方案則將分庫分表等中介軟體實現的功能下推到資料庫層面來做，對應用透明，應用就像使用單機資料庫來使用分散式資料庫，同時天然地支援分散式事務。

 

6、如何進行分散式資料庫專案的系統方案設計？有哪些具體的設計內容？

系統方案主要包括：

①如何進行伺服器選型：

一般分散式資料庫都會採用廉價x86 pc伺服器，搭配本地ssd固態盤、萬兆網路卡，硬體成本較低。

②軟體規劃和部署方案：

分散式資料庫元件眾多，而且每個元件都有高可用備份，所以在有限數量的伺服器下進行元件的分配要儘量考慮達到各個伺服器負載的均衡，gtm作為分散式資料庫的瓶頸儘量和他們元件分開部署。

③監控方案：

監控一般可以採用開源的zabbix進行定製化開發，當然也可以基於grafana+prometheus的方案做監控。

④如何進行調優：

因為不同廠商研發的資料庫sql最佳化器及執行計劃都有所不同，所以要根據不同產品進行學習。

⑤備份方案：

分散式資料庫如何做一致性備份也是研發難點，要做到真正意義上的pitr就需要做到分散式環境下每個全域性事務的“barrier”操作。

⑥應急方案：

因為分散式資料庫還處於發展階段，還不成熟，技術比較複雜，所以生產環境下要制定詳細的應急方案，讓不瞭解分散式資料庫的同事也能夠在出現問題時按照手冊操作。

 

7、在分散式資料庫專案中，為進行系統規格設計，如何進行定量需求分析？需要收集哪些需求資料資訊？

主要考慮以下幾個方面：

①系統的最大併發數：

為了節省成本，多套小系統可以共用一套資料庫，但是負載很大的高併發場景還是獨立搭建。

②系統的最大資料量：

多租戶系統下需要考慮各個系統的資料量之和。

③系統最大可容忍的業務中斷時間：

分散式資料庫節點當機並不是對業務沒有任何影響，主節點當機都涉及到一個切換的問題，切換就是影響業務的時間，要充分評估業務能否忍受這麼長時間的中斷。

④系統的遷移成本：

分散式資料庫不可能做到oracle、db2、mysql所有資料庫的百分之百相容，所以不同型別的資料庫在遷移上都會或多或少的涉及到應用的改造。

 

8、如何解決分散式資料庫專案中的某個難點問題？

我覺得分散式資料庫主要有以下幾個難點：

①分散式事務：分散式事務的實時一致性是分散式資料庫研發的難點，cap理論中分割槽容錯性是一定要保證的，那麼在c和a中我相信對於銀行使用者應該會犧牲可用性來保證一致性。

②效能：為了保證事務全域性一致，分散式資料庫都需要一個全域性事務管理器gtm，用於分配全域性事務id，任何一個事務開啟都需要先去gtm申請事務號，這樣gtm就會成為分散式資料庫的效能瓶頸，廠商所宣稱的效能和機器數量成正比就要打個問號了。

③備份恢復：如何進行全域性一致性備份，如何支援全域性的前滾恢復。

④高可用：分散式資料庫宕掉節點或多或少的都會造成資料庫hang一段時間，對標成熟的網際網路主備架構的切換時間，這個還需要最佳化。

 

9、在分散式資料庫專案中，什麼模組如何進行設計？

分散式資料庫一般包括如下幾個重要模組：

① 訪問層：也叫SQL轉發層。這一層定位在SQL執行計劃的生成和下發，多個訪問層節點理想情況下要進行無狀態設計，使用負載均衡技術統一對外提供服務；負責資料的排序、歸併等集合操作；負責分散式事務的控制。

② 資料層：資料經過分片後儲存在不同的資料節點上，資料節點根據協調節點的請求進行讀寫資料檔案，對資料進行節點內的預處理，同時通常具有一主多從的多副本資料複製能力。

③ 全域性事務管理器：處理全域性事務，為各協調節點生成唯一的全域性事務編號和全域性序列號。因為是分散式資料庫的瓶頸，為了減小gtm的網路互動，可以設計為事務id批次分配，一次分配一段事務號。同時也可以將事務號儲存在分散式儲存中，比如etcd，這樣能避免一些效能和高可用問題。 

  

10、分散式資料庫上線後，如何對運維工作進行管理安排？

分散式資料庫類的運維工作主要包括如下幾類：

① 準備常用運維指令碼、應急手冊、運維手冊等。

② 做好監控，通常要與監控工具進行對接和整合。

③ 做好相關技術手冊培訓。

④ 做好生產演練，如定期的重啟、切換等。