釘釘猛增40倍流量壓力阿里云的DBA們是這樣應(yīng)對的...

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

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

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

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

2月5日釘釘躍居蘋果免費(fèi)AppStore排行榜第一，霸占至今

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

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

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

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

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

以消息模塊為例，在春節(jié)前，釘釘消息日常流量峰值不到千萬，第一次容量評估，大家給2月3號定了個(gè)目標(biāo)是日常峰值的3倍，隨著2月10號開課高峰的到來，又將2月10號的目標(biāo)調(diào)整為10倍，之后又因?yàn)?月17號開學(xué)季的到來，再次將目標(biāo)調(diào)整為40倍。所以總?cè)萘肯啾热粘７逯担?0倍！

2、時(shí)間緊，擴(kuò)容需求眾多，資源不足

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

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

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

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

1、人員合理化安排

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

根據(jù)釘釘業(yè)務(wù)線進(jìn)行分工，每個(gè)DBA跟進(jìn)一個(gè)業(yè)務(wù)線，參與高峰期的保障，及時(shí)播報(bào)線上系統(tǒng)狀況與水位，讓重保決策人員及時(shí)了解系統(tǒng)的狀況。對線上出現(xiàn)的問題緊急處理，保證問題在短時(shí)間內(nèi)得到修復(fù)。對不合理的業(yè)務(wù)場景進(jìn)行優(yōu)化，保證已知問題只出現(xiàn)一次。參與系統(tǒng)的壓測，發(fā)現(xiàn)潛在風(fēng)險(xiǎn)點(diǎn)及時(shí)修正，對系統(tǒng)容量不夠的系統(tǒng)進(jìn)行及時(shí)擴(kuò)容，在資源滿足的情況下讓數(shù)據(jù)庫在高峰來臨之前已經(jīng)具備足夠的容量。

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

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

2、資源緊急協(xié)調(diào)

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

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

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

在系統(tǒng)高峰來臨之前，數(shù)據(jù)庫團(tuán)隊(duì)內(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進(jìn)行緊急干預(yù)

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

預(yù)備數(shù)據(jù)庫弱一致腳本，在必要時(shí)進(jìn)一步提高數(shù)據(jù)庫吞吐

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

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

（紅色曲線是限流量）

4、DB容量預(yù)估及性能分析

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

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

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

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

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

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

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

先展示下效果：

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

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

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