本文作者：阿里云數據庫運維專家箋一、奕信
很近，由于受新型冠狀病毒感染的肺炎疫情影響，釘釘流量出現了飛躍性增長。
自2月3日以來，釘釘持續迎來流量高峰：遠超1000萬家企業使用釘釘在線辦公，總人數超過2億；全國20多個省份200多個教育局啟動了“課程直播”計劃，涉及2萬多個中小學在內的1200多萬的學生。
持續的業務增長也讓釘釘出現了很多歷史性時刻：
2月5日釘釘躍居蘋果免費AppStore排行榜第一，霸占至今
2月6號釘釘上了中心電視臺，釘釘CTO接受采訪
此次疫情流量主要來源于釘釘遠程辦公和在線教育功能，從字面來看，似乎只是釘釘的兩個業務功能，但在釘釘內部依靠模塊不下20個，主要有在消息/視頻會議/直播/家校/健康打卡等業務場景。如何保障超過20個業務在如此爆發式增長下的性能和穩定性，是對釘釘后臺系統、數據庫系統的一個很大挑戰。
本文會從數據庫DBA的視角來介紹下我們是如何打贏這場“戰爭”的，在這個過程中我們究竟碰到了哪些挑戰，我們是如何組織我們的團隊，如何思考，如何真正利用技術克服這些挑戰，很后通過這場戰爭，我們又沉淀了哪些經驗及技術。
數據庫是釘釘業務系統運行的強依靠，在這種類似雙11的場景下，如何規劃部署數據庫成了穩定性中很重要的一環，但是這次的戰爭來的太忽然，我們并沒有很多時間預備，因此我們面臨了非常多的困難與挑戰，總結下來有以下3點：
1、系統所需要的容量是多少，無法預估
以消息模塊為例，在春節前，釘釘消息日常流量峰值不到千萬，第一次容量評估，大家給2月3號定了個目標是日常峰值的3倍，隨著2月10號開課高峰的到來，又將2月10號的目標調整為10倍，之后又因為2月17號開學季的到來，再次將目標調整為40倍。所以總容量相比日常峰值，翻了40倍！
2、時間緊，擴容需求眾多，資源不足
疫情流量的猛增，給系統帶來的沖擊不亞于每年的雙11。電商會花半年時間預備雙11，但這次留給我們的時間只能以小時來計。另一方面，釘釘出于成本的考慮，資源池中基本沒有空余的機器，現有的資源部署密度也比較高，如何騰挪資源在較短的時間內為釘釘接近20個核心集群進行擴容是一個很大的問題。
3、極限場景下如何保障系統穩定性與用戶體驗
在各種因素制約導致集群無法擴容且系統達已經達到瓶頸時我們能怎么辦？有哪些應急手段能用?是否存在一個平衡點，將對用戶的影響降到很低？
忽然間猛增的業務流量也是對釘釘底層數據庫系統，數據庫團隊的一次全面檢驗。依托于底層成熟的管控，DTS，中間件系統，數據庫團隊和釘釘業務團隊緊密合作，通過專業的能力和成熟的產品將上述挑戰一一化解。
1、人員合理化安排
小組成員包含了數據庫團隊DBA/數據庫內核/CORONA/TDDL/DTS/精衛/NOSQL各產品線同學。
根據釘釘業務線進行分工，每個DBA跟進一個業務線，參與高峰期的保障，及時播報線上系統狀況與水位，讓重保決策人員及時了解系統的狀況。對線上出現的問題緊急處理，保證問題在短時間內得到修復。對不合理的業務場景進行優化，保證已知問題只出現一次。參與系統的壓測，發現潛在風險點及時修正，對系統容量不夠的系統進行及時擴容，在資源滿足的情況下讓數據庫在高峰來臨之前已經具備足夠的容量。
由于前期資源有限，需要擴容的系統眾多，每個業務線owner都覺得自己的系統是很重要的，必須要優先擴容自己的數據庫，甚至有些owner拉自己的領導更甚至領導的領導來找DBA提擴容需求。
這給了DBA非常大的壓力，實在是僧多肉少，無力回天，DBA也因此受了不少委屈，這時候釘釘穩定性團隊主動站了出來，幫DBA分擔了大量的的壓力，他們將數據庫的擴容需求根據業務的重要性進行優先級劃分，統一擴容需求，DBA根據優先級順序，結合業務的目標容量進行判定，在有限的資源下有條不紊的進行擴容，保證資源優先用在刀刃上，大大提升了擴容效率。
2、資源緊急協調
疫情忽然爆發，所有人都預期流量會增長，但漲多少誰也不知道，必須要早作預備。為了保證資源不成為系統擴容的阻力。DBA和云資源團隊進行合理規劃，短期內通過借用集團上云的機器，同時縮容其他BU數據庫集群，湊出400臺左右的機器，保證高優先級系統的擴容需求，同時協調云資源進行搬遷，在短短幾天內搬遷了300多臺機器到釘釘資源池，保證了釘釘所有數據庫的擴容需求。
資源到位后就是檢驗數據庫彈性的時候了，依托于PolarDB-X三節點分布式的部署架構，我們可以較為方便的對原有集群進行在線升級和擴容，對用戶影響很低，并保證數據的一致性。有些場景用戶需要從原有集群將數據遷移到分庫分表更多的新集群，我們利用DTS搭配成熟的管控平臺也能較為流暢的完成。很終我們可以做到只要有資源，數據庫也能具有極致的彈性，滿足業務需求。
3、應急與優化
在系統高峰來臨之前，數據庫團隊內部已經預備好緊急預案：
參數降級，調整數據庫參數充分發揮數據庫能力，提高吞吐
資源降級，調整資源限制，CPU隔離放開及數據庫BP大小緊急上調
針對異常SQL，確認影響后緊急限流，或者通過SQLExecutePlanProfile進行緊急干預
全集群流量備庫分流，依據壓力情況很大可100%讀流量切換到備庫
預備數據庫弱一致腳本，在必要時進一步提高數據庫吞吐
同時結合業務的限流/降級預案保證了很多數據庫系統在未知高峰流量到來時的穩定運行。
但業務限流降低了很多用戶的體驗，之前業務限流值設置為30QPM/群，表示為每個群在一分鐘之內只能發送30條消息，很多時候在1分種的前20s甚至更短時間就已經發出30條消息，在剩下時間40s以上時間用戶的體驗就是無法使用釘釘，針對這種情況DBA建議減小限流窗口，將限流值30QPM改成30/20S，限流降低了97%，大大改善了用戶的體驗。
（紅色曲線是限流量）
4、DB容量預估及性能分析
業務上往往通過集群的CPU情況即可大概分析出系統的水位，但是對DB而言不僅是CPU，IO，網絡，SQL，鎖等等，任何一個組件的瓶頸往往都會成為很終容量的瓶頸。不同的業務模型，往往瓶頸都不一樣，即使都是查詢量較大的業務，有些可能是cpu的瓶頸，有些可能是內存命中率不夠導致的瓶頸，有些則是索引設計不合理導致的瓶頸。更復雜的部分在于，有些瓶頸往往不是線性的，可能壓力提升2倍還沒什么問題，硬件能力都還有富余，但是提升到3倍就直接掛了。在這種場景下我們如何比較正確的評估DB的容量呢？
以往我們都是通過經驗并和業務方一起進行全鏈路壓測進行DB容量（集群能支撐多少讀寫）的預估，這種方式有以下幾個問題：
壓測數據集和數據庫總量相比往往比較小，DB命中率基本100%，這對于分析有IO的業務模型存在較大誤差
成本較大，需要打通上下游整個鏈路，較多的同學參與
即使全鏈路壓測，真正壓到DB端的往往也只是核心的幾個接口，無法100%覆蓋線上所有的接口，而很多慢SQL往往都來自這些易忽略的接口
解決這個痛點問題的方法大家其實很簡單想到--只要把線上的業務流量全部采集下往返放一遍即可，但實現起來是非常復雜的。我們真正需要的其實是針對DB的一種通用的單鏈路壓測能力，并不依靠上游業務，DB層可以自己進行流量的生成，放大或縮小，甚至將事務比例更改后再次壓測的能力。
從2021年開始，在DBA和達摩院數據庫實驗室科學家們共同的努力下，我們開發了ClouDBench實現了上述的需求，并在此次的戰爭中幫助DBA進行容量的評估。
先展示下效果：
藍色是真實業務在某個時刻的性能曲線，綠色是我們采集DB端流量回放出來的性能曲線，可以看出兩條曲線在時序上高度擬合，尤其是InnoDB內部的指標都非常接近，包括流量的波動。
當我們能夠比較真實的回放出業務的workload，我們即可以對壓力進行放大，以此來分析DB的容量，并分析出極限場景下的性能瓶頸，從而進行DB的優化及驗證優化效果。
ClouDBench目前已經在共有云數據庫自治服務DatabaseAutonomyService(DAS)中灰度上線，我們會在后續的文章中具體介紹下ClouDBench的實現，敬請期待。
文章地址：http://www.meyanliao.com/article/online/13627.html
