當下泛 DBA 化的趨勢是非常明顯的，一方面業(yè)務(wù)對多類型數(shù)據(jù)庫的實際需求，DBA不能只立足玩轉(zhuǎn)一款數(shù)據(jù)庫產(chǎn)品，關(guān)系型+非關(guān)系型/OLAP+OLTP/圖數(shù)據(jù)庫/消息存儲，但凡跟數(shù)據(jù)有關(guān)的都可能是 DBA 需要去了解的。另一方面上云后 DBA 不用再為過去繁重的基礎(chǔ)設(shè)施穩(wěn)定性保障所拖累，同時云上提供了運維管理相關(guān)的 PaaS 化產(chǎn)品，這很大程度降低了 DBA 管理的復(fù)雜性，因此很多人會認為上云了對 DBA 的依賴就降低了或者干脆就不需要 DBA 了。

從近3年對云實際使用經(jīng)驗看，在人員與業(yè)務(wù)體量小一點的公司對開發(fā)&運維&安全標準規(guī)范都沒有嚴格要求跟約束的情況下是適用的，但是體量稍微大一點就玩不轉(zhuǎn)了，尤其混合云的環(huán)境下依靠云商能力是很難解決自身個性化的需求的。尤其體系化建設(shè)是無法依靠堆“云產(chǎn)品積木”的方式去構(gòu)建。

什么是體系化建設(shè)

提到體系化建設(shè)總給人一種很虛的感覺，到底體系化包含哪些內(nèi)容？主要圍繞著3個方面的能力建設(shè)上：

接下來簡單介紹一下貨拉拉圍繞上述三點進行的相關(guān)能力建設(shè)。

穩(wěn)定性

貨拉拉 DBA 團隊管理了MySQL（阿里云RDS、華為云RDS、AWS-Aurora RDS）、ES、Kafka、RabbitMQ、Redis-Cluster 以及各種組件 Canal/ZK 等)，同時在全球有若干個 IDC，每個 IDC 又包含了多環(huán)境（測試、預(yù)發(fā)、生產(chǎn)），上千人的研發(fā)團隊，這么復(fù)雜的場景跟體量還真的需要一個專業(yè)的團隊來管理。

數(shù)據(jù)庫上云穩(wěn)定性并不能做到5個9，云只是解決了基礎(chǔ)設(shè)施的管理問題，過去DBA在基礎(chǔ)設(shè)施上投入大量的精力主要就是保障基礎(chǔ)設(shè)施的穩(wěn)定性，這么看上云確實能提高基礎(chǔ)設(shè)施的穩(wěn)定性保障水平。但是如何在應(yīng)用層面保障數(shù)據(jù)庫穩(wěn)定性是不在云商保障范疇內(nèi)的。

雖然有的云商提供了數(shù)據(jù)庫自治服務(wù)但是整體看下來還是比較弱的，且不是每家云都具備該能力，而且自治服務(wù)是收費的也并不便宜。

MySQL

SQL事前發(fā)現(xiàn)

通過對預(yù)發(fā)環(huán)境的 SQL 旁路然后將旁路結(jié)果對歷史記錄進行對比就可以很容易發(fā)現(xiàn)每天DB新增了那些慢、危險SQL，然后及時地預(yù)警給測試跟研發(fā)同學(xué)進行優(yōu)化改造。同時與發(fā)布系統(tǒng)打通進行卡口、未優(yōu)化完成的 APPID 禁止發(fā)布，起到攔截作用。

SQL 旁路的前提條件：接入貨拉拉自研的數(shù)據(jù)庫中間件、該中間件覆蓋了所有云 RDS，基于中間件將各個環(huán)境的全量 SQL 旁路且分發(fā)到 Kafka 供數(shù)據(jù)庫管理系統(tǒng) DMS 進行消費處理，每天處理消息量達100億，單純消息分析處理能力對 DBA 就有一定的考驗。

SQL事中兜底

如何無差別防范任何 SQL 在任何場景下?lián)舸?shù)據(jù)庫？一方面數(shù)據(jù)庫中間件會實時感知數(shù)據(jù)庫RT情況，一但RT整體響應(yīng)異常則啟動限流功能，或者 DBA 可以主動介入熔斷、限流特定 SQL，甚至可以干擾執(zhí)行計劃做到走特定索引的功能。

同時 DMS 自愈系統(tǒng)會實時感知數(shù)據(jù)庫 processlist 列表是否有堆積或者長查詢，自愈系統(tǒng)會根據(jù)規(guī)則進行查殺動作，比如 CPU/IO 異常、SQL 執(zhí)行時間超過規(guī)定時間、processlist 列表堆積、鎖等待、連接數(shù)超警戒水位等。自愈系統(tǒng)要跟監(jiān)控系統(tǒng)進行配合才能做到實時的感知能力，這也是需要進行個性化建設(shè)的。

可以看到該保障能力建設(shè)落地后，我們數(shù)據(jù)庫 thread_running/processlist 列表堆積超過30（云上普遍都是4-8C這樣的小規(guī)格活躍SQL數(shù)定在30相對合適的）的實例比例都不到1%（監(jiān)控只要發(fā)現(xiàn)一次就視為異常），日常基于該指標就可以比較直觀的評估最近一段時間數(shù)據(jù)庫穩(wěn)定情況了。

SQL事后治理

研發(fā)可以基于 DMS 系統(tǒng)獲取到對應(yīng)的慢查詢趨勢跟詳情信息，方便研發(fā)進行日常優(yōu)化治理。當然也需要一些系統(tǒng)外的機制保障研發(fā)是在不斷治理的，整個 SQL 防控、兜底、治理就算閉環(huán)了。

可以看到高危慢查詢?nèi)f分率常態(tài)化下都在萬分之一附近波動。

圍繞 SQL 治理我們甚至做了一個類似阿里云的 SQL 洞察的功能，一方面兼容當前所有云產(chǎn)品其次其他云也不具備該功能而且即使有也不便宜！！

SQL發(fā)布變更

其次威脅穩(wěn)定性的來源就是日常數(shù)據(jù)庫的發(fā)布變更了。發(fā)布主要解決3個方面的問題。

1、SQL規(guī)范

就是大家通常說的SQL審核，尤其是在具備一定規(guī)模跟體量的業(yè)務(wù)下SQL規(guī)范是很重要的，一些微小的缺陷都可能被大流量、高負載放大影響。由于開源系統(tǒng)跟我們自研的DMS 系統(tǒng)整合比較困難，索性就重新開發(fā)了一個，通過數(shù)據(jù)運營指標發(fā)現(xiàn)其實研發(fā)是很難遵守規(guī)范的，幾乎每周都有10%做的變更不合規(guī)。所以試圖將云上 DB 直接交給開發(fā)自己維護這一個角度看就很不可行。

2、變更安全

保證 DML 安全執(zhí)行避免更新行數(shù)太大，以及能快速回滾數(shù)據(jù)吳跟新，對 DDL 尤其超大表能安全順利變更完成，尤其我們運行在多家云上每家云的架構(gòu)及內(nèi)核特點都不一樣對DDL的友好性也不同。我們最終還是選擇通用 GH-OST 方式，為了降低鎖/高并發(fā)等對DDL的影響我們也是對 ost 做了很多二次開發(fā)確保 DDL 成功。

3、成功率保障

貨拉拉是家快速成長的公司，每天數(shù)據(jù)庫變更量日均在600+，因此發(fā)布的效率跟成功率是很重要的，效率上我們發(fā)布系統(tǒng)會自動識別部署架構(gòu)比如阿里云我們由于大量使用分庫分表很多集群是沒有 slave 節(jié)點的或者有 slave 節(jié)點單不參與 online 業(yè)務(wù)，對 gh-ost修改后會自動優(yōu)化相關(guān) hook 函數(shù)保證 DDL 效率優(yōu)先。

為應(yīng)對大規(guī)模發(fā)布我們發(fā)布系統(tǒng)被設(shè)計成分布式可以輕松擴容的，當發(fā)布能力不足時加幾個 agent 節(jié)點就可以了，理論上我們能應(yīng)對任何突發(fā)大量規(guī)模發(fā)布。

可以看到我們發(fā)布成功率還是非常高的，同時發(fā)布時長整體也都在10分鐘左右就可以結(jié)束。

Redis

對 Redis 穩(wěn)定性威脅最大的無非就大key、熱key了。

大key、熱key防御

貨拉拉在發(fā)展初期PHP是主流，后續(xù)不同團隊又引入了其他開發(fā)語言，由于我們目前采用的是統(tǒng)一Cluster架構(gòu)，很多語言再對Cluster協(xié)議上支持的不夠完善，最常見的問題就是集群節(jié)點發(fā)生調(diào)整會導(dǎo)致業(yè)務(wù)端長時間感知不到底層變化業(yè)務(wù)持續(xù)性故障，還有就是PHP短連接等問題，因此我們設(shè)計了一套代理來解決多語言的問題。

對PHP短連接服務(wù)實現(xiàn)短鏈變長鏈，由于是 sidecar 部署模式引用到 mesh 層的網(wǎng)絡(luò)開銷就比較小，應(yīng)用RT與Redis節(jié)點CPU分別下了40%、60%。

對大key、熱key也有了更好的應(yīng)對方案，比如對大key限流/block訪問，大key導(dǎo)致的危害一下就解決了，比如下圖因大key導(dǎo)致的網(wǎng)絡(luò)流量異常限流效果立竿見影。

對熱key進行本地化緩存+低粒度更新，rt增高問題迅速得到緩解。

Kafka

Kafka 本身其實是比較穩(wěn)定的，但是對業(yè)務(wù)而言穩(wěn)定性風險主要來自自身消費延遲感知問題，過去研發(fā)普遍會在消費系統(tǒng)里面埋點以此來感知消費延遲情況，但是實際效果上效果不是太理想，主要原因在于現(xiàn)在的延遲度量方式都是以 lags 這維度的，是比較抽象的。

延遲發(fā)現(xiàn)

基于時間維度的延遲度量是更直觀的，對研發(fā)更加友好。我們設(shè)計了兩個獨立方式：

該方式比較簡單由于要消費消息取時間戳因此效率非常低，但是比較準確。

該方式不需要消費消息效率非常高，準確度略差。

新的延遲度量有效解決研發(fā)對延遲度量上的焦慮，研發(fā)可以通過系統(tǒng)比較簡單的配置就可以訂閱消費延遲告警，也不需要再系統(tǒng)內(nèi)進行埋點。

資源/故障隔離

實際運維過程中來自 Kafka 本身的故障非常少，日常穩(wěn)定性問題主要集中在諸如網(wǎng)絡(luò)、磁盤異常導(dǎo)致的整體業(yè)務(wù)抖動，以及在防范一些 topic 生產(chǎn)或者消費導(dǎo)致的資源嚴重占用造成的相互響應(yīng)問題。針對這個問題 DMS 系統(tǒng)設(shè)計了一個租戶的概念，DMS 對集群broker 節(jié)點進行編組構(gòu)成一個 Zone，創(chuàng)建 topic 時將 topic 指定到特定 Zone，實際創(chuàng)建時通過 go-sarama 接口將 topic 指定到特定機器（Zone），如下圖：

這樣設(shè)計的好處是實現(xiàn)資源隔離的目的、故障隔離的目的。比如某個Zone的機器異常不會影響其整體，同時對于單個Topic讀寫過大導(dǎo)致的資源占用也能很好的應(yīng)對，同時還解決了Topic自由調(diào)度的問題，比如可以將一個小規(guī)格Topic遷移到大的Zone內(nèi)，過程是對業(yè)務(wù)無感的也不用換鏈接地址。最后對提高資源利用率有很好的作用，因為不同Zone用的機器規(guī)格可能是不同的，日常擴縮容可以精確到Zone，避免集群整體擴容造成的浪費及業(yè)務(wù)影響。

ES、MQ

篇幅原因不一一介紹了。

賦能運維&研發(fā)效率

1、賦能 DBA

前面介紹過了貨拉拉的基礎(chǔ)環(huán)境其實是非常復(fù)雜的，DB選型多種類多，分布在幾朵云上，每朵云都有獨立運行的環(huán)境，DBA其實是很難通過云產(chǎn)品進行有效管理，如果只用單一云服務(wù)且體量有比較小依靠云 PaaS 產(chǎn)品也能解決一些日常問題，這顯然不適合我們。

站在DBA跟研發(fā)的角度看都有共同的訴求：通過一個入口一個平臺搞定所有日常運維需求+研發(fā)所有需求，因為站點、環(huán)境、選型太多了，先不論云上是否提供了類似能力，即使有對于一個上千人的研發(fā)團隊也是極其低效的。因此一套大一統(tǒng)的系統(tǒng)架構(gòu)是必要的。

對DBA而言無非就是通過系統(tǒng)將日常工作自動化掉，且在一套系統(tǒng)上完成。

整體對DBA而言日常90%以上的工作可以借助平臺完成。

2、賦能研發(fā)

對研發(fā)而言無外乎就是資源申請、發(fā)布、告警訂閱、變更、安全等自助化服務(wù)，這些由于內(nèi)嵌了公司的很多流程、SOP 這一點云商 PaaS 是很難解決的。

DBA日常維護了MySQL、Redis、Kafka、ES、MQ等中間件，支持上千人的研發(fā)團隊，日常咨詢量減去知識庫攔截率實際需要DBA人工支持的Case每天不足20個，研發(fā)日常大部分需求都可以通過DMS自主解決。

科學(xué)合理的資源使用

成本治理大致兩個手段：運維手段進行資源治理、技術(shù)手段進行資源合理利用。

以我們成本占用比較高的MySQL、Kafka為例。運維上通過縮容、將配我們很快榨干了明顯使用不合理的資源。在需要有所突破就很難了，因此需要在技術(shù)上找到新的增長點。

MySQL

由于云是規(guī)格整體是偏小的應(yīng)對突發(fā)異常的情況是比較弱的，我們將數(shù)據(jù)庫拆分的比較細因此我們下掉了大部分slave節(jié)點。

經(jīng)典存算一體架構(gòu)下存儲與計算是存在綁定關(guān)系的，不管是云上還是自建都會存在這樣的關(guān)系，比如在云上你要買3T的存儲你的CPU都不能低于8C，或者你要買一個16C算力你的存儲不能少于3TB，這就會出現(xiàn)算力與存儲不匹配的問題，造成算力跟存儲的浪費。自建IDC下尤其如此 因為方便統(tǒng)一運維與硬件采購可能所有數(shù)據(jù)庫服務(wù)器的規(guī)格配置是一致的這個浪費更加明，搞過自建的同學(xué)應(yīng)該深有體會。今天我們可以充分利用云的能力來最大程度的提升我們的資源利用率加上我們自建能力及云的能力實現(xiàn)既便宜又好用。后續(xù)ServerLess架構(gòu)成熟后相信成本控制上會有更豐富的手段。

自建環(huán)境下是很難將平均存儲使用率做到這么高的，在2023H1結(jié)束前我們預(yù)計存儲平均使用率能做到75%以上。CPU平均使用率15%左右，做到這一點是非常困難的，要兼顧成本跟容量安全，這塊我們前面在穩(wěn)定性介紹里提到了我們是具備比較強的應(yīng)急處理能力的，確保我們具備探索更多的可能。

Kafka

基于前面介紹的多租戶的方式、不同場景使用不同配置的租戶，不同租戶內(nèi)實現(xiàn)定向擴縮容，能有效的避免Topic間資源分布不均導(dǎo)致的資源浪費。

Kafka歷史上為應(yīng)對突發(fā)消息暴漲我們規(guī)定了存儲使用超過50%可能就要擴容了，當前的磁盤、CPU平均使用率還是比較高的。

我對DBA的理解

1. 運維型 DBA：這是偏常見DBA的工作，能很好的在當下管理體系下按照標準完成日常工作，比如基本問題的處理、研發(fā)對接等。
   
   
2. 開發(fā)型 DBA：懂開發(fā)似乎是今天 DBA 的標配能力了，這類嚴格來說不是DBA了，我們今天一直說的泛化 DBA 其實就指的這類型的 DBA，而不是說你可以維護幾款數(shù)據(jù)庫產(chǎn)品，對他們的要求是很高的，一方面懂數(shù)據(jù)庫，懂數(shù)據(jù)運維，懂開發(fā)(前端+后端)，懂數(shù)據(jù)庫周邊生態(tài)工具，以及快速的學(xué)習能力，因為上云的大趨勢下 DBA 不在為基礎(chǔ)設(shè)施所拖累 DBA 承載的面就要擴展，最后可能還是自己的產(chǎn)品經(jīng)理，因為沒有人給你畫原型圖也沒有人告訴你頁面該長成什么樣子，什么地方該放什么按鈕以及他是什么顏色的…，這些都要建立在上述復(fù)雜的要求之上。
3. DBA 架構(gòu)師：這類 DBA 是經(jīng)驗+意識型的 DBA，對數(shù)據(jù)庫有深度的理解、綜合技術(shù)全面、對內(nèi)知道什么階段做什么事有清晰的規(guī)劃，對外能搞定研發(fā)并建立良好的團隊協(xié)作關(guān)系、能扛事也能搞事(推動做事)、建立個人及團隊整體影響力。

個人覺得上云后 DBA 的分布也應(yīng)該是橄欖型的，大量的開發(fā)型 DBA 承擔基建工作，很少量的運維型 DBA 仍舊承擔傳統(tǒng) DBA 的部分工作，DBA 架構(gòu)師來掌控全局。

作者簡介：

蔡朋@貨拉拉

10年+DBA工作經(jīng)歷曾就職餓了么、螞蟻，現(xiàn)任貨拉拉數(shù)據(jù)庫部門負責人，負責數(shù)據(jù)庫、緩存，消息隊列的管理與平臺研發(fā)工作。