官术网_书友最值得收藏!

2.5 GoldenDB數據庫應用開發和運維實踐

以中信銀行GoldenDB所代表的新一代原生分布式數據庫,具有強一致性、線性擴展和高可用性,可以更好地滿足商業銀行應用開發和運維發展的需要。

但是,轉型到分布式數據庫后,并不是一帆風順的,還會面臨很對挑戰。一方面,應用人員和開發人員需要正視挑戰并采用具體舉措,才能真正駕馭好GoldenDB數據庫;另一方面,商業銀行要遵守人民銀行相關規范,以推動分布式數據庫開發和運維的標準化。

2.5.1 分布式數據庫帶來的挑戰

分布式數據庫實現了數據去中心化,但是由于其自身特點,也給應用開發和運維帶來了一些挑戰,下面分別闡述。

1.應用開發方面的挑戰

GoldenDB數據庫實現了對應用透明,從功能角度,應用開發人員只要按照ANSI SQL標準語言去編寫SQL語句完成業務邏輯。但從性能角度,還要注意在聯機交易負載下,低效的應用程序將會對分布式數據庫帶來以下挑戰。

(1)應用程序中過于復雜的SQL語句將會影響數據庫性能。

例如這樣的SQL語句:超過3張以上的大表關聯、返回大結果集等,這些都會消耗數據庫過多的處理資源,導致響應時間變慢。

(2)應用程序中不帶分片鍵的SQL語句將會影響數據庫性能。

例如,不帶分片鍵的SQL語句,將會導致DBProxy將應用請求發給所有分片,將會導致查詢時間變慢。

(3)過多的跨節點分布式事務將會影響數據庫性能。

例如,一個跨節點轉賬的應用程序被并發方式執行,將會發起大量的跨節點事務,這將消耗數據庫的處理資源,有可能導致事務執行時間變長。

2.運維方面的挑戰

相較于應用開發,運維方面的挑戰更多。從集中式到分布式數據庫,對整個傳統的運維體系有較大沖擊,帶來了很大挑戰,具體包括以下內容。

(1)節點多且關聯復雜。

集中式數據庫運行在少數幾臺服務器上,但分布式數據庫的各種節點運行在數百臺服務器上,節點關系復雜,運維復雜度高,靠人工運維不現實,需要通過平臺化運維的新思路,統一上報告警及統計信息、統一日志中心、自動化監控、自動化運維、自動化巡檢等。

(2)x86服務器可靠性低,穩定性弱。

集中式數據庫通常運行在小型機上,小型機故障率低。但是分布式數據庫運行的x86服務器穩定性低于小型機,單機故障率增加。這就要求對所有節點的服務器和數據都進行冗余配置,當出現節點故障時,啟動自動化應急,通過主備切換保證服務的持續可用性。

(3)部署結構復雜。

一個分布式系統不僅包括數據庫,還包括應用多活集群、Redis緩沖集群等,部署架構復雜,這就意味著當出現軟件或者硬件問題時,很難定位故障節點。因此,需要一套多維立體化監控手段,準確定位故障節點,并通過自動化應急在規定時間內解決故障。

上面探討了分布式數據庫引入對應用開發和運維方面的挑戰。實際上,目前商業銀行的應用開發和運維之間的界限已經相當模糊,開發人員和運維人員都需要掌握操作系統和數據庫相關技能,還要掌握Java、Python等開發技能。建議引入DevOps流程,實現開發和運維一體化。

什么是DevOps?

DevOps(Development和Operations的組合詞)是一組過程、方法與系統的統稱,用于促進開發、運維部門之間的溝通、協作與整合。

它是一種重視“軟件開發人員(Dev)”和“IT運維技術人員(Ops)”之間溝通合作的文化、運動或慣例。通過自動化“軟件交付”和“架構變更”流程,來使得構建、測試、發布軟件能夠更加快捷、頻繁和可靠。

它的出現是由于人們日益清晰地認識到:為了按時交付軟件產品和服務,開發和運維工作必須緊密合作。

2.5.2 應用開發方面的應對措施

針對應用開發方面遇到的上述挑戰,根本上是性能問題,但引起性能問題的根源卻有多種。這是因為分布式架構下表數據被切分到多個數據節點,查詢語句需要考慮語句如何拆分、分片之間數據如何移動、結果如何計算與合并的問題。下面分場景給出應對措施。

場景1:SQL兼容性問題。

GoldenDB完全兼容MySQL語法。但部分語句在分布式環境下執行代價過大,暫不放開這些執行代價過大的語句。解決方案如下。

通過產品迭代,完善執行效率、逐步放開代價過大的SQL語句功能。

場景2:SQL語句執行效率低。

由于數據切分到多個數據節點,查詢操作涉及網絡通信的交互次數和交換的數據量較多時,會造成SQL語句性能變慢。此時需要根據執行計劃進行針對性優化。解決方案如下。

(1)產品通過迭代,給出更好的執行計劃和查詢性能。

(2)提供增強型EXPLAIN命令分析SQL語句從計算節點到數據節點完整的執行計劃,原生MySQL的EXPLAIN命令僅可以查看數據節點自身的執行計劃。

(3)增強型慢查詢日志功能,可更詳細地看到各個階段耗時。

(4)針對不同的業務場景提供多種隔離級別,如果業務允許臟讀,可使用UR隔離級別,提升性能。

(5)提供多種HINT語句,可以指定SQL語句到某個分片上執行。

場景3:由于鎖沖突導致性能低下。

解決方案如下。

(1)增加數據節點鎖沖突信息日志功能,記錄所有鎖沖突超過設定時間的記錄。

(2)調整鎖等待時間參數:根據最佳實踐,將應用的查詢超時時間設定為合適值(例如10 s),數據庫的行鎖等待時間調整為合適值(例如8s),減少由于行鎖等待導致的查詢超時概率;元數據鎖等待時間調整為合適值(例如5s),減少長時間的DDL語句執行期間,查詢語句由于元數據鎖等待導致語句卡住較長時間的情況。

場景4:多分片不均勻問題。

分布不均勻問題主要是數據分布不均勻和數據訪問不均勻。解決方案如下。

(1)使用數據重分布功能重新分布數據。

(2)引入技術分片鍵,例如,表中有字段A存儲客戶號,引入字段B,字段B初始存儲的內容和字段A完全一致,字段B為分片鍵,若其中某個節點的客戶號訪問量較多或客戶號存儲較多,可將該節點的部分數據導出,修改字段B的內容,再重新導入,人為將數據分布均勻。

2.5.3 生產運維方面的應對措施

針對分布式數據庫運維,應對措施的關鍵是要建立一套“監、管、控”的運維體系,以向智能化、數字化邁進。整個運維體系主要涉及監控、巡檢、性能優化、應急處置、擴展性等問題,下面具體闡述。

1.監控

相較于集中式數據庫,分布式數據庫組件眾多,通過單一種類的監控或使用現有的手段定位問題比較困難,需要一套或者多套監控體系配合來幫助運維人員精準確定位到故障節點。

GoldenDB數據庫提供了一套心跳監控機制以及告警系統,在網絡出現波動或者問題時能夠第一時間發現并且上報。為滿足實際運維需求,某商業銀行采用了如下告警系統。

(1)通過IBM ITM監控工具對服務器上的進程、端口號、關鍵字等基礎項進行了監控。

(2)通過NPM監控,對所有組件節點進行網絡流量變化進行實時監控,并能夠針對性抓包分析。

(3)通過交易監控系統,對業務響應率、業務成功率和交易耗時等進行監控,以便實時發現并定位分析。

(4)通過普羅米修斯軟件,對各個組件的服務器資源(CPU、I/O、內存等),以及DB節點相關資源監控(主從狀態、主從延遲、緩沖池命中率、寫掛起等)進行實時監控。

(5)將分布式數據庫各個節點產生的日志定期上傳到日志中心,通過ELK平臺對日志進行匯總和篩選,方便問題排查。

2.巡檢

分布式數據庫集群中各個模塊均為多節點,模塊間關聯性較大,這就要求分布式數據庫巡檢工具按照以下要求設計。

(1)能夠滿足系統日常基本項巡檢。例如,服務器資源型通用巡檢CPU、I/O、內存、存儲空間、內存交換空間、文件描述符使用情況等。

(2)能夠滿足各組件特性巡檢。例如,對DB節點緩沖池命中率、表碎片化等數據庫相關指標巡檢;對DBProxy的連接數、消息積壓等情況的巡檢;對管理節點中各個管理進程的連接狀態、集群切換狀態等情況的巡檢等。

(3)能夠對各個組件的巡檢進行判斷和分類,進行巡檢控制。例如,應該在DB上進行的巡檢就不要在DBProxy上進行。

(4)能夠對所有節點的巡檢結果進行匯總收集,歸類,將問題精確定位到節點IP、巡檢內容、報錯信息等,方便運維人員進行快速定位和查詢。

分布式數據庫的巡檢,在一定程度上展示了分布式數據庫運行情況的發展趨勢,可以配合監控數據更早地定位出系統的潛在問題。

3.應急處置

分布式數據庫涉及的組件多,不能依賴DBA手工應急,必須實現自動化應急,真正做到“預防為主,處置高效”。建議商業銀行采用以下方案進行。

(1)編寫分布式數據庫應急手冊。

(2)根據分布式數據庫應急手冊開發自動化應急腳本,以實現自動化應急功能。

4.性能分析和優化

分布式數據庫出現性能問題,如整體性能偏低、交易出現波動等,需要及時發現問題,在此不再贅述,僅列舉兩個場景的例子。

場景1:慢查詢問題。

解決方案:檢查計算節點和數據節點慢查詢日志,根據慢查詢日志判斷原因,例如SQL語句需要優化、磁盤繁忙等。

場景2:計算節點、數據節點出現資源使用高、響應慢等問題。

解決方案:根據分布式數據庫應急手冊處置,打印當前組件狀態、內存信息、內部調度信息等,隨后進行針對性優化。

5.擴展性

擴展性包括縱向擴展和橫向擴展,縱向擴展通過增加機器硬件資源實現,橫向擴展通過增加數據節點實現。通過橫向擴展增加數據節點之后,數據需要進行重分布操作,操作期間會因數據傳輸導致磁盤繁忙。建議可以采用以下方案。

(1)重分布之前規劃磁盤空間,確保空間足夠。

(2)重分布變更需要在業務交易較少的時間段執行。

6.備份和恢復

分布式數據庫數據節點多,對數據備份和恢復的要求很高,建議采用集中備份軟件,例如NBU,進行多節點數據備份。

(1)為了不影響交易,建議在備機上備份。

(2)多節點同時備份,提升備份效率。

2.5.4 技術規范的制定和落實

當前階段,各大商業銀行都在逐漸引入分布式數據庫,可謂如火如荼。為了推進分布式數據庫研發和運維的標準化,中國人民銀行發布了指導性的分布式數據庫技術規范。

2020年11月26日,中國人民銀行發布了三項金融行業標準:《分布式數據庫技術金融應用規范——技術架構》(JR/T 0203—2020)、《分布式數據庫技術金融應用規范——安全技術要求》(JR/T 0204—2020)、《分布式數據庫技術金融應用規范——災難恢復要求》(JR/T 0205—2020)。

《分布式數據庫技術金融應用規范——技術架構》規定了在金融領域分布式事務數據庫的架構要求,涵蓋技術框架、功能特性和運維管理,旨在保障金融服務高可用、數據高可靠、彈性可擴展、產品高適配和數據易遷移。

《分布式數據庫技術金融應用規范——安全技術要求》規定了在金融領域分布式事務數據庫的安全要求,涵蓋基礎支撐保障、用戶管理、訪問控制、數據安全、監控預警、密鑰管理、安全管理和安全審計等內容,旨在保障金融業務安全穩定運行。

《分布式數據庫技術金融應用規范——災難恢復要求》規定了在金融領域分布式事務數據庫的災難恢復要求,涵蓋容災能力分級、災備技術要求和災備管理流程,旨在引導金融機構建立健全容災機制,保障金融業務連續性運行。

分布式數據庫金融應用系列標準適用于金融領域分布式事務數據庫的研發、測試、評估和應用,為分布式數據庫金融應用標準體系夯實基礎。

針對中國人民銀行發布的上述技術規范,各大商業銀行在分布式數據庫的開發和運維中,需要抓緊落實并實踐;也建議商業銀行之間多開展技術規范方面的同業交流,通過交流提升運用分布式數據庫的水平。

主站蜘蛛池模板: 离岛区| 鄂温| 锡林浩特市| 秭归县| 江西省| 彭水| 泸州市| 安平县| 集安市| 垦利县| 新邵县| 碌曲县| 罗平县| 保定市| 同江市| 常德市| 洪江市| 凌云县| 宝兴县| 大关县| 衡阳县| 丘北县| 宜良县| 临洮县| 河北区| 承德县| 乌海市| 旬阳县| 安龙县| 巢湖市| 武义县| 永定县| 时尚| 吉木萨尔县| 碌曲县| 烟台市| 丽江市| 修水县| 榆社县| 甘泉县| 湘潭县|