[[319472]]

分布式架構可能是近幾年最火的話題。從集中式、SOA到分布式架構，本文回顧了這些年金融行業(yè)經歷的架構演變;結合當下一些較典型的分布式數(shù)據(jù)庫的實現(xiàn)原理，分析了分布式數(shù)據(jù)庫的三個發(fā)展階段。分布式數(shù)據(jù)庫的應用解決了傳統(tǒng)數(shù)據(jù)庫性能擴展問題的同時，也給運維人員帶來了挑戰(zhàn)。那么，分布式數(shù)據(jù)庫的管理究竟多了些什么?如何管理好?未來數(shù)據(jù)庫和數(shù)據(jù)庫運維又將去往何方?讀過本文，你可以找到答案。

 

一、金融行業(yè)這些年經歷了怎樣的架構演變?

1. 集中式架構

分布式架構可能是近幾年最火的話題，與之相對的則是集中式架構，后者是傳統(tǒng)金融行業(yè)如銀行最常見的部署架構。在“去IOE”之前，各大銀行的目標還停留在將集中式單點做強做大，不少銀行采用IBM的主機系統(tǒng)就是鮮明的例子。數(shù)據(jù)庫服務器更是如此，通常都是采用最好的機器。

近幾年，隨著銀行業(yè)務增長，互聯(lián)網行業(yè)爆發(fā)，用戶行為模式發(fā)生變化，集中式架構的系統(tǒng)面臨很大的挑戰(zhàn)。問題主要體現(xiàn)在擴展性和可用性這兩方面：

1. 擴展性

集中式架構的橫向水平擴展能力非常低。面對性能不足，用戶能做的就是加CPU、加內存、換存儲、換機器等方式。

2. 可用性

集中式架構的服務能力依賴高性能的主機。然而一旦主機出現(xiàn)故障，上面的服務就會受到影響。應對這個問題的方案就是搭建高可用架構。每一個環(huán)節(jié)都需要考慮冗余和HA。集中式架構下這幾乎是最好的方式了。然而無論哪個環(huán)節(jié)出故障，影響的都是全局服務。

這種架構下的數(shù)據(jù)庫也是通過做主備機冗余，HA服務自動管理切換滿足高可用性。性能方面通常也是采用縱向擴容的方式。然而縱向擴容是有限制的。如果最強的主機都搞不定了怎么辦?

 

 

 

 

圖 1. 集中式架構

在集中式架構的數(shù)據(jù)庫里面有一個例外，那就是MPP數(shù)據(jù)庫。為了解決單節(jié)點數(shù)據(jù)庫性能上限問題，某些數(shù)據(jù)庫廠商開發(fā)出來MPP數(shù)據(jù)庫。這種數(shù)據(jù)庫算是一套集群，數(shù)據(jù)分布在這些集群的節(jié)點上，數(shù)據(jù)查詢服務也能下推到這些節(jié)點完成。通過數(shù)據(jù)分發(fā)和功能分發(fā)，充分利用多節(jié)點的處理能力，這簡直就是現(xiàn)在的分布式先驅。

 

 

 

 

圖 2. 集中式MPP架構

圖中協(xié)調節(jié)點CN并非是一個特殊組件，這可以是任何一個DN。不過這類產品是面向OLAP的，是為了解決大查詢問題，和現(xiàn)在分布式的方向并不一樣。

2. 面向服務的架構(SOA)

在互聯(lián)網浪潮還沒到來，分布式架構還未興起的時候，為了解決單機性能瓶頸和全局服務可用性問題，最初的方案是業(yè)務拆分，也就是面向服務的架構(SOA)開始應用起來。純粹的SOA其實是一個組件模型，它將應用程序的不同功能單元(稱為服務)進行拆分，并通過這些服務之間定義良好的接口和協(xié)議聯(lián)系起來。SOA架構曾經流行了一段時間，當然現(xiàn)在更火的是微服務模式。

 

 

 

 

圖 3. SOA架構

當時有很多銀行將自己的核心系統(tǒng)依照這個思路拆分，一個大系統(tǒng)拆成多個小系統(tǒng)或者是組件。優(yōu)點是服務拆分之后實現(xiàn)了部分性能擴展。之所以說是部分，是因為總有些核心服務是熱點，沒有辦法做到拆分的。隨之帶來的缺點是系統(tǒng)調用鏈復雜程度增加了，數(shù)據(jù)在不同服務間的同步要求變多變復雜，然后系統(tǒng)和服務器的數(shù)量增多了。即便是采用了SOA的思路，還是沒有徹底解決熱點功能的性能問題和可用性問題：

1. 沒有實現(xiàn)核心功能的水平擴展，單個功能還是屬于集中式架構部署。

2. 沒有實現(xiàn)數(shù)據(jù)水平拆分，解決不了大數(shù)據(jù)量的問題，反而帶來了不同系統(tǒng)數(shù)據(jù)同步的復雜需求。

3. 分布式架構

就在金融行業(yè)還在忙著為系統(tǒng)功能拆分改造，給新的小機打預算的同時，中國的互聯(lián)網科技行業(yè)正在發(fā)生大的變革。

大數(shù)據(jù)技術發(fā)展：第一大變革是各種分布式開源軟件走向成熟并被充分利用。分布式存儲、分布式計算、分布式消息中間件引領大數(shù)據(jù)行業(yè)變革。這些分布式技術簡單粗暴的解決了大數(shù)據(jù)量、高吞吐量和高可用性的難題。這些難題對業(yè)務系統(tǒng)和后臺的數(shù)據(jù)庫同樣存在?？雌饋頂?shù)據(jù)庫走向分布式才是終極解決方案。然數(shù)據(jù)庫行業(yè)的領先者們并沒有像擁抱云技術那樣去擁抱分布式數(shù)據(jù)庫，反而給了眾多初創(chuàng)數(shù)據(jù)庫企業(yè)機會。

互聯(lián)網消費行為：另外一大變革是互聯(lián)網行業(yè)改變了用戶的消費行為。這幾年網絡運營商在提速降費，互聯(lián)網移動設備出貨量飆升，用戶的消費習慣也大量從線下轉移到線上。中國的人口紅利在互聯(lián)網產業(yè)發(fā)揮的淋漓盡致。對于金融行業(yè)來說，用戶消費行為的變化帶來的是對金融科技的挑戰(zhàn)。交易量和數(shù)據(jù)量都在不停攀升高峰。尤其是網銀，手機銀行等渠道類業(yè)務都將面臨集中式架構性能瓶頸問題。

其中最典型的就是阿里。阿里從2011年開始基于成本因素的考慮逐步去IOE，同時年年祭出了雙十一成績單。高帥富的小機替換成了PC機，Oracle數(shù)據(jù)庫換成了開源MySQL數(shù)據(jù)庫，同時自研分布式中間件TDDL實現(xiàn)橫向擴展。阿里通過堆砌廉價的PC機來支撐龐大的雙十一促銷業(yè)務，最終交出了交易量、峰值、金額等漂亮的成績單?，F(xiàn)在阿里的分布式中間件發(fā)展成了關系型數(shù)據(jù)庫 DRDS。同時阿里還有面向金融領域全自研內核的OceanBase，主打云數(shù)據(jù)庫存儲計算分離架構的PolarDB。

技術自主可控：這幾年國際關系大環(huán)境也在發(fā)生變化，國內尋求自主可控的聲音越來越響。相應的國內也涌現(xiàn)出了很多主打數(shù)據(jù)庫產品和服務的企業(yè)。尤其是分布式數(shù)據(jù)庫技術，在國際數(shù)據(jù)庫領頭羊們還沒有全力投入拿出作品的時候，國內很多企業(yè)借鑒開源分布式技術方案，研發(fā)出了自己的分布式數(shù)據(jù)庫。因為沒有作業(yè)可抄，所以大家做的作業(yè)也很不一樣。

綜上所述，內有金融行業(yè)對于大數(shù)據(jù)量、高吞吐量和高可用性的迫切需求以及自主可控的需求，外有大數(shù)據(jù)分布式技術方案得到肯定，再加上互聯(lián)網行業(yè)解決方案引領，金融行業(yè)對國內優(yōu)秀的分布式數(shù)據(jù)庫的需求持續(xù)走強。

二、分布式數(shù)據(jù)庫經歷了哪幾個發(fā)展階段?

分布式數(shù)據(jù)庫是為了解決大數(shù)據(jù)量、高吞吐量和高可用性的問題，通過數(shù)據(jù)和計算分片的方式提供橫向擴展能力。然而思路很明確，實現(xiàn)很復雜。為了更清楚當前一些分布式數(shù)據(jù)庫的實現(xiàn)原理，我們首先將要數(shù)據(jù)庫分為三層來看待：解析層，計算層，存儲層。而分布式的實現(xiàn)就是在解決這幾層的實現(xiàn)問題。我把分布式數(shù)據(jù)庫的發(fā)展分為三個階段。

1. 讀寫分離

為了解決集中式架構下的單節(jié)點計算性能問題，首先出現(xiàn)的方案是讀寫分離模式。當時MySQL開源數(shù)據(jù)庫比較流行。然而MySQL單節(jié)點的處理性能很容易遇到瓶頸。MySQL主從復制的架構下，主庫可讀寫，然而備庫建議只讀。因此如果SQL解析層能夠做到讀寫分離，那么主庫的壓力將會大大降低。

 

 

 

 

圖 4. 讀寫分離架構

這種架構曾經流行一段時間，這個階段MySQL發(fā)展勢頭也很迅猛，開始挑戰(zhàn)商業(yè)數(shù)據(jù)庫的地位。商業(yè)數(shù)據(jù)庫的用戶也向IBM和Oracle等提出了相關的需求。這種架構下每個數(shù)據(jù)節(jié)點的數(shù)據(jù)是全量的?？蛻舳嘶蛘呤菙?shù)據(jù)庫中間件需要解決SQL的讀寫分發(fā)問題：如何保證數(shù)據(jù)一致性，如何設計SQL的隔離級別，如何解決鎖問題等等。

• 解析層

解析層需要實現(xiàn)讀寫分發(fā)。

• 計算層

實現(xiàn)了從庫接受讀交易，一定程度分散了壓力。

• 存儲層

單節(jié)點是全量數(shù)據(jù)。數(shù)據(jù)同步通過數(shù)據(jù)庫的主從復制技術實現(xiàn)。

如果存儲計算分離，然后實現(xiàn)分布式存儲。那么這種架構又可以進一步解決存儲層的壓力問題?，F(xiàn)在最典型的是阿里云的polardb。

 

 

 

 

圖 5. 阿里云polardb分布式存儲

阿里云的polardb實現(xiàn)遠遠比簡單的讀寫分離要豐富的多。首先這是個面向云的原生數(shù)據(jù)庫，是屬于軟硬一體的解決方案。

• 解析層

實現(xiàn)讀寫分離和負載均衡。

• 計算層

縱向擴展單節(jié)點性能，橫向擴展讀性能。

• 存儲層

分布式存儲，分片方式對應用透明。通過FPGA，RDMA等硬件技術加速性能。

個人認為云數(shù)據(jù)庫是未來的趨勢，阿里polardb和騰訊tdsql會大放異彩。

2. 分布式中間件模式

讀寫分離還是不能滿足中國互聯(lián)網龐大的用戶體量。銀行有幾千萬上億的用戶，互聯(lián)網更多。但凡來個促銷活動，運維人員就心驚肉跳。僅僅靠讀寫分離其實不能滿足這種集中并發(fā)式的性能瓶頸。那么能不能將這些用戶的交易數(shù)據(jù)分開放在不同的節(jié)點上，讓這些用戶只在對應的節(jié)點處理數(shù)據(jù)呢?這就是現(xiàn)在分布式的主流思路：數(shù)據(jù)分片。

 

 

 

 

圖 6. 數(shù)據(jù)庫中間件

圖中的每個分片都可以是一套主從架構的數(shù)據(jù)庫，不僅僅是一個物理節(jié)點。

• 解析層

實現(xiàn)sql分發(fā)查詢以及結果匯聚。數(shù)據(jù)分片的定義需要在這一層保存。對于跨節(jié)點的分布式事務支持能力很單薄。這個主要看分布式中間件的產品能力。

• 計算層

通過底層數(shù)據(jù)的分片，計算層已經完全實現(xiàn)了負載分離。

• 存儲層

數(shù)據(jù)分片后，存儲層的性能問題也完美解決。

這種架構的典型代表是阿里最初的TDDL數(shù)據(jù)庫中間件產品和開源數(shù)據(jù)庫中間件Mycat。阿里的TDDL數(shù)據(jù)庫中間件已經演變成現(xiàn)在的DRDS集群。

首先我們來看看Mycat的解決方案。

 

 

 

 

圖 7. Mycat數(shù)據(jù)庫中間件

Mycat數(shù)據(jù)庫中間件架設在應用和底層數(shù)據(jù)庫之間。應用SQL會解析轉化并路由到底層多個數(shù)據(jù)庫主備集群里。這種方案不需要底層數(shù)據(jù)庫做任何改動。然而支持復雜SQL的能力有限。使用這種架構要避免分布式事務。

下面看看阿里云的DRDS解決方案。DRDS雖然是中間件模式，不過現(xiàn)在推出的解決方案更像是個完整的分布式集群數(shù)據(jù)庫。DRDS是分布式中間件，底層是RDS數(shù)據(jù)庫集群(mysql)。RDS數(shù)據(jù)庫服務是阿里云提供的關系型數(shù)據(jù)庫服務統(tǒng)稱，主要是MySQL。DRDS通過兩階段提交來實現(xiàn)分布式事務。

 

 

 

 

圖 8. 阿里云DRDS

如果存在分布式的事務，那么在這種架構下最好由應用層面去解決。這方面我覺得做的最好的是招商銀行。招行一開始就將分布式事務和分片的角色都放在業(yè)務應用開發(fā)層面，因此不需要依賴底層數(shù)據(jù)庫來實現(xiàn)分庫分表。

3. 分布式集群模式

中間件模式其實還是和數(shù)據(jù)庫引擎脫離的。分布式中間件如果將中間件和底層數(shù)據(jù)庫揉在一起，當做一個產品去開發(fā)使用，這就是現(xiàn)在的分布式集群數(shù)據(jù)庫。我觀察了國內各家廠商分布式數(shù)據(jù)庫的實現(xiàn)，基本濃縮成下面這張示意圖。

 

 

 

 

圖 9. 分布式數(shù)據(jù)庫集群

協(xié)調節(jié)點：這是分布式數(shù)據(jù)庫接受用戶請求和返回數(shù)據(jù)的處理節(jié)點，通常以多活的模式部署在多個物理節(jié)點上。協(xié)調節(jié)點之間的事務控制通過向全局管理節(jié)點請求，獲取全局事務信息或者鎖信息。協(xié)調節(jié)點的SQL會編譯執(zhí)行，調取對應的數(shù)據(jù)節(jié)點。

數(shù)據(jù)節(jié)點：真正存放數(shù)據(jù)的地方。從協(xié)調節(jié)點導入的數(shù)據(jù)通過分片或者復制的方式存放在數(shù)據(jù)節(jié)點里面。數(shù)據(jù)節(jié)點通常只需要響應協(xié)調節(jié)點的調取。數(shù)據(jù)節(jié)點通過一主多備的模式提高數(shù)據(jù)可用性。備節(jié)點一般不提供讀取服務。

全局管理節(jié)點：分布式數(shù)據(jù)庫的核心，也是區(qū)別于分布式中間件方案的關鍵組件。全局管理節(jié)點用于全局事務控制、元數(shù)據(jù)管理等。這些需要全局控制的功能可能會被拆分成多個組件來部署，這也是不同分布式數(shù)據(jù)庫集群的根本差異。

集群管理節(jié)點：這是數(shù)據(jù)庫集群高可用性的保證。用于全局監(jiān)控數(shù)據(jù)庫各項組件的狀態(tài)，并且依據(jù)狀態(tài)變化自動響應。集群管理節(jié)點控制著整個集群里組件的切換和維護。

上述邏輯節(jié)點可以在物理節(jié)點上混部署，加上數(shù)據(jù)中心的概念。集群可以跨多中心部署實現(xiàn)數(shù)據(jù)中心級的容災。國內現(xiàn)在比較突出分布式數(shù)據(jù)庫gaussT、TIDB、glodendb、sequoiadb、antdb等都是這類架構。下面看兩個典型的國產化數(shù)據(jù)案例，與大部分分布式數(shù)據(jù)庫的解決方案不一樣的是，他們的數(shù)據(jù)庫引擎不是基于MySQL。

第一個是華為的高斯數(shù)據(jù)庫gaussT。

 

 

 

 

圖 10. 華為gaussT數(shù)據(jù)庫

這是華為官方的高斯數(shù)據(jù)庫。其中ETCD和CM是集群管理器，用來選擇和操作整個集群。其中ETCD存放集群整體狀態(tài)信息，基于paxos協(xié)議保證可用性。CN是接受用戶請求的協(xié)調節(jié)點，負責數(shù)據(jù)和SQL的分發(fā)和匯總。CN多活，客戶端通過負載均衡模式連接CN。GTS是全局事務管理節(jié)點，僅處理事務號的請求并且有緩存機制，因此相對處理性能比較高。DN是數(shù)據(jù)節(jié)點，一主多備模式保證高可用。集群內部的表有兩種方式建立，一種是選好分布鍵的分片數(shù)據(jù)表，一種是全局同步復制的復制表。從高斯數(shù)據(jù)庫的架構來說，它是典型的傳統(tǒng)關系型數(shù)據(jù)庫的升華版：全面支持分布式事務，集群當做一個數(shù)據(jù)庫來用的方式對用戶友好。

說到分布式數(shù)據(jù)庫也要提到TIDB。TIDB是PingCAP公司推出的開源分布式數(shù)據(jù)庫。在一幫做分布式數(shù)據(jù)庫的廠家中，TIDB是個另類，另辟蹊徑主打先進的數(shù)據(jù)庫架構和良好的開源生態(tài)。

 

 

 

 

圖 11. TIDB數(shù)據(jù)庫

在TIDB的架構圖里，TiDB Cluster是接受請求的協(xié)調節(jié)點，用作SQL解析和轉發(fā)。TiKV是存放數(shù)據(jù)的數(shù)據(jù)節(jié)點。與其他分布式數(shù)據(jù)庫不同的是TIDB用的是分布式的KV存儲引擎。TIDB的數(shù)據(jù)分發(fā)也和其他分布式數(shù)據(jù)庫必須指定分區(qū)鍵分片規(guī)則不同，實現(xiàn)的是基于Region級別的raft復制，還可以根據(jù)負載情況進行合并和分裂。這個特點是其他分布式數(shù)據(jù)庫做不到的。PD Cluster相當于是全局事務管理器。集群管理器在圖中沒有標出來，其實里面的每個cluster都有相應的集群服務。

三種分布式方案已經介紹差不多了，最后來看看中興Goldendb吧。

 

 

 

 

圖 12. GoldenDB三種部署形態(tài)

中興Goldendb將這三種部署形態(tài)全部集成。No-Sharding就是單機部署一主多備模式，提供讀寫分離的負載方案。Sharding集群就是中間件部署模式，計算節(jié)點做轉發(fā)，不支持分布式事務。Distribute Transaction集群就是加了GTM全局事務管理器，支持分布式事務。

4. 分布式數(shù)據(jù)庫測試體會

介紹了這么多分布式數(shù)據(jù)庫架構，我們也測試了很多家的數(shù)據(jù)庫產品。這里談談銀行在測試分布式過程中的一些經驗：

1. 對于單點數(shù)據(jù)的增刪改查，大家的性能都很好，極限瓶頸一般出現(xiàn)在全局事務管理這個環(huán)節(jié)。因此這部分的性能差異就在于這個全局事務的處理問題上。這也決定了一個分布式數(shù)據(jù)庫的性能上限。

2. 對于分布式事務，需要跨節(jié)點數(shù)據(jù)訪問的，大家的性能都不怎么好。其實分布式事務對于分布式數(shù)據(jù)庫來說還是有很大挑戰(zhàn)的。對于使用分布式數(shù)據(jù)庫的業(yè)務，建議減少分布式事務，也不要把分布式數(shù)據(jù)庫當做混合負載來用。尤其是像不同分布鍵的大表關聯(lián)，搞垮協(xié)調節(jié)點是分分鐘的。這部分技術還是面向數(shù)倉的MPP數(shù)據(jù)庫比較合適。如果MPP數(shù)據(jù)庫的這部分能力被集成到分布式數(shù)據(jù)庫中，那這個分布式數(shù)據(jù)庫才真是厲害了，從容面對HTAP。

3. 使用分布式數(shù)據(jù)庫一定要關注分布鍵。無論是分片還是復制，業(yè)務開發(fā)人員需要從自己的業(yè)務邏輯開發(fā)，合理設置。一旦選不好，分布式數(shù)據(jù)庫還不如單節(jié)點性能。

4. 分布式數(shù)據(jù)庫數(shù)據(jù)重分布，也就是橫向擴展，都是痛點。無論是操作方式還是性能影響，基本上所有的分布式數(shù)據(jù)庫都成問題?？赡苁褂米詣臃植伎蓴U展的存儲引擎才是最終解決方案。

5. 分布式數(shù)據(jù)庫集群組件眾多，相對來說管理比較復雜。每個組件都有自己的日志，都可能有性能瓶頸。在分布式數(shù)據(jù)庫環(huán)境下運維管理成本比較高。

三、傳統(tǒng)數(shù)據(jù)庫運維崗面臨哪些挑戰(zhàn)?

分布式數(shù)據(jù)庫的應用解決了傳統(tǒng)數(shù)據(jù)庫性能擴展問題的同時，也給運維人員帶來了挑戰(zhàn)。以前一套標準就可以運維好傳統(tǒng)數(shù)據(jù)庫，定好參數(shù)規(guī)則，做好應急防護即可。現(xiàn)在多了分布式數(shù)據(jù)庫，并不只是多了個數(shù)據(jù)庫產品那么簡單，而是多了種數(shù)據(jù)庫的使用方式。

1. 分布式數(shù)據(jù)庫管理多了什么?

統(tǒng)一數(shù)據(jù)視圖：分布式數(shù)據(jù)庫數(shù)據(jù)做了分片之后，運維人員需要解決數(shù)據(jù)透視的問題。哪些表是分片表，哪些表是復制表?如果需要導出或者同步數(shù)據(jù)到其他系統(tǒng)，這個方案該怎么做?一張表被分成了多少份，整體的數(shù)據(jù)量是多少?如果選擇了分布式數(shù)據(jù)庫成熟產品還好，這些部分有產品級的解決方案。中間件型的分布式就更難了。對于用戶來說，如果還能將集群里的數(shù)據(jù)當做一個數(shù)據(jù)庫來操作是最理想的。

大量節(jié)點管理：選擇分布式，就是選擇橫向擴展。相應的運維節(jié)點數(shù)量會出現(xiàn)爆發(fā)式增長。這個運維力量一下子就上去了。還好需要上分布式的系統(tǒng)不會太多?，F(xiàn)在這些節(jié)點不僅都需要單獨監(jiān)控管理，還需要管理好節(jié)點的角色。

容量管理：這里的容量管理包含性能和數(shù)據(jù)兩個方面。在分布式環(huán)境下一定要關注負載分布問題。因為從根本上來說分布式就是為了解決性能負載而誕生的。運維人員需要檢測到負載是否均衡，是否符合預期，如果有問題，需要從數(shù)據(jù)分布和業(yè)務行為的角度一起去分析。這相對是比較復雜和困難的。另一方面，分布式數(shù)據(jù)庫里面最怕出現(xiàn)數(shù)據(jù)傾斜問題。嚴重的數(shù)據(jù)傾斜會導致性能瓶頸和容量瓶頸。出現(xiàn)傾斜后如何數(shù)據(jù)重分布也是很難的問題。

數(shù)據(jù)一致性：分布式數(shù)據(jù)庫的數(shù)據(jù)一致性可能會被用戶忽略。因為在集中式數(shù)據(jù)庫中很少會出現(xiàn)這種問題。然而分布式數(shù)據(jù)庫的分布式事務基本都是通過兩階段提交的方式來實現(xiàn)。出現(xiàn)問題的情況下可能會出現(xiàn)提交殘留。因此用戶需要定時檢查數(shù)據(jù)庫是否存在兩階段提交殘留，定時比對數(shù)據(jù)。

變更管理：分布式環(huán)境下的變更問題也需要重視。節(jié)點變多了，數(shù)據(jù)庫拆散了，變更也就存在全局和單點的維度。如何統(tǒng)一變更保證集群所有機器都完成而沒有遺漏?是不是所有的節(jié)點都變更了?能不能通過定時參數(shù)比對等方式提示參數(shù)不一樣的節(jié)點?

容災方案：分布式數(shù)據(jù)庫的災備方案該怎么做?兩地三中心采用什么方式實現(xiàn)?異構數(shù)據(jù)庫的數(shù)據(jù)同步方案有哪些?數(shù)據(jù)遷移方案呢?這些在單節(jié)點數(shù)據(jù)庫的情況下有很多成熟并久經考驗的方案可以使用。然而在分布式環(huán)境下，現(xiàn)在只能說是陪著廠商一起成長。

多租戶管理：多租戶管理是分布式數(shù)據(jù)庫環(huán)境需要解決的重要功能。運維人員需要把相應的產品方案用起來，并且在運維的過程中關注租戶的容量和性能需求，并相應調整數(shù)據(jù)庫。

2. 如何管理好分布式數(shù)據(jù)庫

分布式數(shù)據(jù)庫作為新的技術，并不是脫胎于成熟的商業(yè)數(shù)據(jù)庫，因此還有很多粗糙的地方。尤其是金融行業(yè)的用戶，被傳統(tǒng)商業(yè)數(shù)據(jù)庫“嬌生慣養(yǎng)”，首次接觸到新生數(shù)據(jù)庫的時候，會有四處碰壁的感覺。但是即便是硬骨頭，還是得啃。

控制應用場景：

分布式不是萬能的，它是面向特殊場景的數(shù)據(jù)庫產品。只有符合的交易才能往上遷移。如果不想自己麻煩，那就別麻煩分布式數(shù)據(jù)庫了。這個要求運維人員不僅僅在看產品，還需要與業(yè)務人員和開發(fā)人員緊密合作。要從業(yè)務分片的角度去管理數(shù)據(jù)庫。因此使用分布式數(shù)據(jù)庫必須定義一個使用場景規(guī)范。

統(tǒng)一管理平臺：

分布式數(shù)據(jù)庫的數(shù)據(jù)分片后，運維人員需要了解數(shù)據(jù)的整體規(guī)劃是什么樣子的，數(shù)據(jù)分片規(guī)則，復制方案，同步方案等。使用分布式數(shù)據(jù)庫集群的用戶可能要輕松一些，因為這些產品可能有相應的產品級解決方案。而采用了分布式中間件的用戶，如何還能隨時查詢和透視數(shù)據(jù)表的關系，這是需要另尋方案的。不管是何種方式，這些都是分布式數(shù)據(jù)庫運維需要做好的事情。

所以運維人員需要建立一套數(shù)據(jù)管理平臺。在平臺里查看和操作分布式數(shù)據(jù)庫集群狀態(tài)，管理數(shù)據(jù)庫用戶、權限、分布規(guī)則、配置下發(fā)、配置比對、查看日志、分析等各類管理功能。最好也包含多租戶管理。

智能監(jiān)控平臺：

引進分布式數(shù)據(jù)庫之后，運維人員需要監(jiān)控分布式數(shù)據(jù)庫節(jié)點狀態(tài)和各個節(jié)點的性能。首先要解決的問題是將新數(shù)據(jù)庫接入到監(jiān)控告警平臺。原先適用于單機數(shù)據(jù)庫的各項監(jiān)控需要針對集群數(shù)據(jù)庫適配一遍。然后更進一步，運維人員還需要借助智能運維來實現(xiàn)分布式數(shù)據(jù)庫的精細化監(jiān)控。智能監(jiān)控平臺需要分析發(fā)現(xiàn)分布式數(shù)據(jù)庫負載不均衡，節(jié)點行為離群等問題，然后智能化展示故障影響鏈條。智能監(jiān)控平臺還能夠做性能容量趨勢分析和預測，提前警示性能容量告警。

容量管理：

這個主題單獨列出來，確實是因為這個主題太重要了。一定要有辦法能夠監(jiān)控數(shù)據(jù)傾斜問題和負載傾斜問題，并且在管理平臺里需要做好負載重分布和數(shù)據(jù)重分布功能。分布式數(shù)據(jù)庫支持的數(shù)據(jù)分片方式一般有三種：hash、range和list。如果發(fā)生了數(shù)據(jù)傾斜問題，運維人員需要查看傾斜原因，并采用這現(xiàn)有的幾種方式嘗試繼續(xù)打散數(shù)據(jù)。因此在容量管理這方面，運維人員需要與業(yè)務及開發(fā)人員緊密溝通，了解數(shù)據(jù)的業(yè)務信息，獲取業(yè)務增長預期，這樣才能做好性能和容量規(guī)劃。

變更發(fā)布：

數(shù)據(jù)庫的參數(shù)變更可以通過統(tǒng)一管理平臺來實現(xiàn)。但是如果管理平臺沒有集成的功能，變更內容也一定需要借助自動化發(fā)布平臺來做。尤其是存在多數(shù)據(jù)中心容災的情況下，人為變更是很容易遺漏的。最好是上線DevOps平臺，將分布式數(shù)據(jù)庫的變更也集成在平臺里。

通過建立這些管理平臺和工具，將數(shù)據(jù)庫運維人員從忙于解決各種問題的窘境中釋放出來，成長為數(shù)據(jù)架構師。DBA向前與業(yè)務場景對接，向后挑選合適的數(shù)據(jù)庫技術，基于標準化自動化的部署維護方式，為業(yè)務穩(wěn)定運行保駕護航。

四、未來，數(shù)據(jù)庫和數(shù)據(jù)庫運維將去往何方?

我們正處在一個數(shù)據(jù)庫技術大爆炸的時代。這幾年NoSQL數(shù)據(jù)庫、NewSQL數(shù)據(jù)庫、時序數(shù)據(jù)庫、圖數(shù)據(jù)庫、分布式數(shù)據(jù)庫、超融合數(shù)據(jù)庫相關的技術百花齊放，國產數(shù)據(jù)庫也強勢發(fā)展起來。那么下一代主流數(shù)據(jù)庫是什么樣子呢?未來的運維模式又將發(fā)生什么變化?

云數(shù)據(jù)庫：系統(tǒng)上云已經成為這幾年的熱點。大廠也紛紛推出自己的云數(shù)據(jù)庫。未來云數(shù)據(jù)庫將會成為趨勢。數(shù)據(jù)庫服務將進一步標準化輸出。無論是私有云還是公有云，用戶的數(shù)據(jù)庫使用方式正在發(fā)生變化。而分布式數(shù)據(jù)庫和超融合數(shù)據(jù)庫的強勁性能，也適合在云環(huán)境提供多租戶使用。

細分領域：數(shù)據(jù)庫應用領域也會越來越細分?？赡墁F(xiàn)在我們還是希望有能夠面向HTAP場景的全能數(shù)據(jù)庫，但是未來數(shù)據(jù)庫功能將更加分化。尤其是通過數(shù)據(jù)庫云可以輕易申請到主打不同功能的數(shù)據(jù)庫來解決各類業(yè)務場景。

智能運維：隨著數(shù)據(jù)庫提供云部署云服務，數(shù)據(jù)庫運維一定需要走向智能運維。通過機器學習智能算法來監(jiān)控系統(tǒng)運行狀態(tài)，依據(jù)數(shù)據(jù)表現(xiàn)提供決策、自動修復、自動擴容。

最后想象一個場景，用戶申請了云數(shù)據(jù)庫，運行一段時間后，智能運維機器人告訴用戶數(shù)據(jù)庫最近發(fā)生了什么事情，一共發(fā)生了幾次自動調優(yōu)，幾次自動修復異常等，共節(jié)省了多少時間損失。還會基于用戶的使用場景，建議用戶擴容或者是購買更適合的數(shù)據(jù)庫服務，將有助于提高性能多少百分比等。

以上是筆者認為在不久的將來即將發(fā)生的變化，你有什么看法?

【作者】孔再華，IBM認證高級DBA，SAP認證BASIS，具有豐富的數(shù)據(jù)庫環(huán)境問題診斷和性能調優(yōu)的經驗。在數(shù)據(jù)庫同城雙活，集群，多分區(qū)，分布式等項目實施上具有豐富的經驗。現(xiàn)任職于中國民生銀行科技部，工作致力于數(shù)據(jù)庫同城雙活架構建設，數(shù)據(jù)庫分布式架構建設和數(shù)據(jù)庫智能運維(AIOps)方向。對于如何將AI技術運用在運維領域具有濃厚的興趣和創(chuàng)新熱情。