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

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

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

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

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

穩(wěn)定性

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

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

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

MySQL

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

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

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

SQL事中兜底

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

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

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

SQL事后治理

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

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

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

SQL發(fā)布變更

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

1、SQL規(guī)范

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

2、變更安全

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

3、成功率保障

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

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

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

Redis

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

大key、熱key防御

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

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

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

對(duì)熱key進(jìn)行本地化緩存+低粒度更新，rt增高問(wèn)題迅速得到緩解。

Kafka

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

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

基于時(shí)間維度的延遲度量是更直觀的，對(duì)研發(fā)更加友好。我們?cè)O(shè)計(jì)了兩個(gè)獨(dú)立方式：

該方式比較簡(jiǎn)單由于要消費(fèi)消息取時(shí)間戳因此效率非常低，但是比較準(zhǔn)確。

該方式不需要消費(fèi)消息效率非常高，準(zhǔn)確度略差。

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

資源/故障隔離

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

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

ES、MQ

篇幅原因不一一介紹了。

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

1、賦能 DBA

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

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

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

整體對(duì)DBA而言日常90%以上的工作可以借助平臺(tái)完成。

2、賦能研發(fā)

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

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

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

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

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

MySQL

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

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

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

Kafka

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

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

我對(duì)DBA的理解

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

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

作者簡(jiǎn)介：

蔡朋@貨拉拉

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