本文作者：阿里云數(shù)據(jù)庫運維專家箋一探索、奕信

很近，由于受新型冠狀病毒感染的肺炎疫情影響情況較常見，釘釘流量出現(xiàn)了飛躍性增長生產體系。

自2月3日以來很重要，釘釘持續(xù)迎來流量高峰：遠超1000萬家企業(yè)使用釘釘在線辦公服務效率，總?cè)藬?shù)超過2億；全國20多個省份200多個教育局啟動了“課程直播”計劃深化涉外，涉及2萬多個中小學(xué)在內(nèi)的1200多萬的學(xué)生開展試點。

持續(xù)的業(yè)務(wù)增長也讓釘釘出現(xiàn)了很多歷史性時刻：

2月5日釘釘躍居蘋果免費AppStore排行榜第一推進一步，霸占至今

2月6號釘釘上了中心電視臺簡單化，釘釘CTO接受采訪

此次疫情流量主要來源于釘釘遠程辦公和在線教育功能系統性，從字面來看，似乎只是釘釘?shù)膬蓚€業(yè)務(wù)功能試驗，但在釘釘內(nèi)部依靠模塊不下20個製度保障，主要有在消息/視頻會議/直播/家校/健康打卡等業(yè)務(wù)場景的有效手段。如何保障超過20個業(yè)務(wù)在如此爆發(fā)式增長下的性能和穩(wěn)定性應用情況，是對釘釘后臺系統(tǒng)應用前景、數(shù)據(jù)庫系統(tǒng)的一個很大挑戰(zhàn)運行好。

本文會從數(shù)據(jù)庫DBA的視角來介紹下我們是如何打贏這場“戰(zhàn)爭”的首次，在這個過程中我們究竟碰到了哪些挑戰(zhàn)，我們是如何組織我們的團隊部署安排，如何思考搖籃，如何真正利用技術(shù)克服這些挑戰(zhàn)，很后通過這場戰(zhàn)爭推廣開來，我們又沉淀了哪些經(jīng)驗及技術(shù)推動。

數(shù)據(jù)庫是釘釘業(yè)務(wù)系統(tǒng)運行的強依靠，在這種類似雙11的場景下資源配置，如何規(guī)劃部署數(shù)據(jù)庫成了穩(wěn)定性中很重要的一環(huán)信息，但是這次的戰(zhàn)爭來的太忽然，我們并沒有很多時間預(yù)備大力發展，因此我們面臨了非常多的困難與挑戰(zhàn)豐富內涵，總結(jié)下來有以下3點：

1、系統(tǒng)所需要的容量是多少產能提升，無法預(yù)估

以消息模塊為例適應性，在春節(jié)前，釘釘消息日常流量峰值不到千萬通過活化，第一次容量評估落地生根，大家給2月3號定了個目標(biāo)是日常峰值的3倍，隨著2月10號開課高峰的到來健康發展，又將2月10號的目標(biāo)調(diào)整為10倍有效保障，之后又因為2月17號開學(xué)季的到來，再次將目標(biāo)調(diào)整為40倍長效機製。所以總?cè)萘肯啾热粘７逯迪嘟Y合，翻?0倍！

2製高點項目、時間緊，擴容需求眾多範圍和領域，資源不足

疫情流量的猛增有所增加，給系統(tǒng)帶來的沖擊不亞于每年的雙11。電商會花半年時間預(yù)備雙11更高要求，但這次留給我們的時間只能以小時來計越來越重要的位置。另一方面，釘釘出于成本的考慮的可能性，資源池中基本沒有空余的機器不要畏懼，現(xiàn)有的資源部署密度也比較高服務為一體，如何騰挪資源在較短的時間內(nèi)為釘釘接近20個核心集群進行擴容是一個很大的問題。

3逐漸顯現、極限場景下如何保障系統(tǒng)穩(wěn)定性與用戶體驗

在各種因素制約導(dǎo)致集群無法擴容且系統(tǒng)達已經(jīng)達到瓶頸時我們能怎么辦全會精神？有哪些應(yīng)急手段能用?是否存在一個平衡點，將對用戶的影響降到很低拓展基地？

忽然間猛增的業(yè)務(wù)流量也是對釘釘?shù)讓訑?shù)據(jù)庫系統(tǒng)集中展示，數(shù)據(jù)庫團隊的一次全面檢驗。依托于底層成熟的管控體系流動性，DTS探索創新，中間件系統(tǒng)，數(shù)據(jù)庫團隊和釘釘業(yè)務(wù)團隊緊密合作實現了超越，通過專業(yè)的能力和成熟的產(chǎn)品將上述挑戰(zhàn)一一化解新產品。

1、人員合理化安排

小組成員包含了數(shù)據(jù)庫團隊DBA/數(shù)據(jù)庫內(nèi)核/CORONA/TDDL/DTS/精衛(wèi)/NOSQL各產(chǎn)品線同學(xué)橋梁作用。

根據(jù)釘釘業(yè)務(wù)線進行分工長遠所需，每個DBA跟進一個業(yè)務(wù)線，參與高峰期的保障拓展應用，及時播報線上系統(tǒng)狀況與水位生產創效，讓重保決策人員及時了解系統(tǒng)的狀況。對線上出現(xiàn)的問題緊急處理管理，保證問題在短時間內(nèi)得到修復(fù)優化上下。對不合理的業(yè)務(wù)場景進行優(yōu)化，保證已知問題只出現(xiàn)一次模樣。參與系統(tǒng)的壓測生產體系，發(fā)現(xiàn)潛在風(fēng)險點及時修正，對系統(tǒng)容量不夠的系統(tǒng)進行及時擴容很重要，在資源滿足的情況下讓數(shù)據(jù)庫在高峰來臨之前已經(jīng)具備足夠的容量能力和水平。

由于前期資源有限，需要擴容的系統(tǒng)眾多異常狀況，每個業(yè)務(wù)線owner都覺得自己的系統(tǒng)是很重要的研究，必須要優(yōu)先擴容自己的數(shù)據(jù)庫，甚至有些owner拉自己的領(lǐng)導(dǎo)更甚至領(lǐng)導(dǎo)的領(lǐng)導(dǎo)來找DBA提擴容需求應用創新。

這給了DBA非常大的壓力競爭激烈，實在是僧多肉少，無力回天改善，DBA也因此受了不少委屈空白區，這時候釘釘穩(wěn)定性團隊主動站了出來，幫DBA分擔(dān)了大量的的壓力，他們將數(shù)據(jù)庫的擴容需求根據(jù)業(yè)務(wù)的重要性進行優(yōu)先級劃分形勢，統(tǒng)一擴容需求實踐者，DBA根據(jù)優(yōu)先級順序，結(jié)合業(yè)務(wù)的目標(biāo)容量進行判定約定管轄，在有限的資源下有條不紊的進行擴容數據，保證資源優(yōu)先用在刀刃上，大大提升了擴容效率業務指導。

2改進措施、資源緊急協(xié)調(diào)

疫情忽然爆發(fā)，所有人都預(yù)期流量會增長長足發展，但漲多少誰也不知道今年，必須要早作預(yù)備。為了保證資源不成為系統(tǒng)擴容的阻力結構不合理。DBA和云資源團隊進行合理規(guī)劃動手能力，短期內(nèi)通過借用集團上云的機器，同時縮容其他BU數(shù)據(jù)庫集群意見征詢，湊出400臺左右的機器提升，保證高優(yōu)先級系統(tǒng)的擴容需求，同時協(xié)調(diào)云資源進行搬遷的必然要求，在短短幾天內(nèi)搬遷了300多臺機器到釘釘資源池研究成果，保證了釘釘所有數(shù)據(jù)庫的擴容需求。

資源到位后就是檢驗數(shù)據(jù)庫彈性的時候了完善好，依托于PolarDB-X三節(jié)點分布式的部署架構(gòu)大面積，我們可以較為方便的對原有集群進行在線升級和擴容，對用戶影響很低問題分析，并保證數(shù)據(jù)的一致性培養。有些場景用戶需要從原有集群將數(shù)據(jù)遷移到分庫分表更多的新集群，我們利用DTS搭配成熟的管控平臺也能較為流暢的完成更加完善。很終我們可以做到只要有資源形式，數(shù)據(jù)庫也能具有極致的彈性，滿足業(yè)務(wù)需求十大行動。

3左右、應(yīng)急與優(yōu)化

在系統(tǒng)高峰來臨之前，數(shù)據(jù)庫團隊內(nèi)部已經(jīng)預(yù)備好緊急預(yù)案：

參數(shù)降級綜合措施，調(diào)整數(shù)據(jù)庫參數(shù)充分發(fā)揮數(shù)據(jù)庫能力傳承，提高吞吐

資源降級，調(diào)整資源限制建言直達，CPU隔離放開及數(shù)據(jù)庫BP大小緊急上調(diào)

針對異常SQL，確認(rèn)影響后緊急限流，或者通過SQLExecutePlanProfile進行緊急干預(yù)

全集群流量備庫分流充分發揮，依據(jù)壓力情況很大可100%讀流量切換到備庫

預(yù)備數(shù)據(jù)庫弱一致腳本發展成就，在必要時進一步提高數(shù)據(jù)庫吞吐

同時結(jié)合業(yè)務(wù)的限流/降級預(yù)案保證了很多數(shù)據(jù)庫系統(tǒng)在未知高峰流量到來時的穩(wěn)定運行。

但業(yè)務(wù)限流降低了很多用戶的體驗重要方式，之前業(yè)務(wù)限流值設(shè)置為30QPM/群開展面對面，表示為每個群在一分鐘之內(nèi)只能發(fā)送30條消息，很多時候在1分種的前20s甚至更短時間就已經(jīng)發(fā)出30條消息非常重要，在剩下時間40s以上時間用戶的體驗就是無法使用釘釘進一步提升，針對這種情況DBA建議減小限流窗口，將限流值30QPM改成30/20S營造一處，限流降低了97%改革創新，大大改善了用戶的體驗。

（紅色曲線是限流量）

4取得顯著成效、DB容量預(yù)估及性能分析

業(yè)務(wù)上往往通過集群的CPU情況即可大概分析出系統(tǒng)的水位新模式，但是對DB而言不僅是CPU，IO不容忽視，網(wǎng)絡(luò)組織了，SQL，鎖等等說服力，任何一個組件的瓶頸往往都會成為很終容量的瓶頸搶抓機遇。不同的業(yè)務(wù)模型，往往瓶頸都不一樣表示，即使都是查詢量較大的業(yè)務(wù)全面闡釋，有些可能是cpu的瓶頸，有些可能是內(nèi)存命中率不夠?qū)е碌钠款i拓展基地，有些則是索引設(shè)計不合理導(dǎo)致的瓶頸集中展示。更復(fù)雜的部分在于，有些瓶頸往往不是線性的分享，可能壓力提升2倍還沒什么問題共享，硬件能力都還有富余，但是提升到3倍就直接掛了方式之一。在這種場景下我們?nèi)绾伪容^正確的評估DB的容量呢生動？

以往我們都是通過經(jīng)驗并和業(yè)務(wù)方一起進行全鏈路壓測進行DB容量（集群能支撐多少讀寫）的預(yù)估，這種方式有以下幾個問題：

壓測數(shù)據(jù)集和數(shù)據(jù)庫總量相比往往比較小創新能力，DB命中率基本100%新品技，這對于分析有IO的業(yè)務(wù)模型存在較大誤差

成本較大，需要打通上下游整個鏈路求得平衡，較多的同學(xué)參與

即使全鏈路壓測紮實做，真正壓到DB端的往往也只是核心的幾個接口，無法100%覆蓋線上所有的接口，而很多慢SQL往往都來自這些易忽略的接口

解決這個痛點問題的方法大家其實很簡單想到--只要把線上的業(yè)務(wù)流量全部采集下往返放一遍即可提供深度撮合服務，但實現(xiàn)起來是非常復(fù)雜的服務品質。我們真正需要的其實是針對DB的一種通用的單鏈路壓測能力，并不依靠上游業(yè)務(wù)組成部分，DB層可以自己進行流量的生成影響，放大或縮小，甚至將事務(wù)比例更改后再次壓測的能力的過程中。

從2021年開始發展契機，在DBA和達摩院數(shù)據(jù)庫實驗室科學(xué)家們共同的努力下，我們開發(fā)了ClouDBench實現(xiàn)了上述的需求促進進步，并在此次的戰(zhàn)爭中幫助DBA進行容量的評估發力。

先展示下效果：

藍色是真實業(yè)務(wù)在某個時刻的性能曲線，綠色是我們采集DB端流量回放出來的性能曲線競爭激烈，可以看出兩條曲線在時序上高度擬合持續創新，尤其是InnoDB內(nèi)部的指標(biāo)都非常接近，包括流量的波動空白區。

當(dāng)我們能夠比較真實的回放出業(yè)務(wù)的workload協調機製，我們即可以對壓力進行放大，以此來分析DB的容量形勢，并分析出極限場景下的性能瓶頸實踐者，從而進行DB的優(yōu)化及驗證優(yōu)化效果。

ClouDBench目前已經(jīng)在共有云數(shù)據(jù)庫自治服務(wù)DatabaseAutonomyService(DAS)中灰度上線服務機製，我們會在后續(xù)的文章中具體介紹下ClouDBench的實現(xiàn)貢獻力量，敬請期待。