本文作者：阿里雲資料庫運維專家箋一、奕信
最近，由於受新型冠狀病毒感染的肺炎疫情影響，釘釘流量出現了飛躍性增長。
自2月3日以來，釘釘持續迎來流量高峰：遠超1000萬家企業使用釘釘線上辦公，總人數超過2億；全國20多個省份200多個教育局啟動了“課程直播”計劃，涉及2萬多箇中小學在內的1200多萬的學生。
- 2月5日釘釘躍居蘋果免費App Store排行榜第一，霸佔至今
此次疫情流量主要來源於釘釘遠端辦公和線上教育功能，從字面來看，好像只是釘釘的兩個業務功能，但在釘釘內部依賴模組不下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 、人員合理化安排
1）資料庫團隊成立疫情期間釘釘業務保障小組
小組成員包含了資料庫團隊DBA/資料庫核心/CORONA/TDDL/DTS/精衛/NOSQL各產品線同學。根據釘釘業務線進行分工，每個DBA跟進一個業務線，參與高峰期的保障，及時播報線上系統狀況與水位，讓重保決策人員及時瞭解系統的狀況。對線上出現的問題緊急處理，保證問題在短時間內得到修復。對不合理的業務場景進行最佳化，保證已知問題只出現一次。參與系統的壓測，發現潛在風險點及時修正，對系統容量不夠的系統進行及時擴容，在資源滿足的情況下讓資料庫在高峰來臨之前已經具備足夠的容量。2）資料庫團隊與釘釘穩定性團隊緊密合作
由於前期資源有限，需要擴容的系統眾多，每個業務線owner都覺得自己的系統是最重要的，必須要優先擴容自己的資料庫，甚至有些owner拉自己的領導更甚至領導的領導來找DBA提擴容需求。這給了DBA非常大的壓力，實在是僧多肉少，無力迴天，DBA也因此受了不少委屈，這時候釘釘穩定性團隊主動站了出來，幫DBA分擔了大量的的壓力，他們將資料庫的擴容需求根據業務的重要性進行優先順序劃分，統一擴容需求，DBA根據優先順序順序，結合業務的目標容量進行判斷，在有限的資源下有條不紊的進行擴容，保證資源優先用在刀刃上，大大提升了擴容效率。2、 資源緊急協調
疫情突然爆發，所有人都預期流量會增長，但漲多少誰也不知道，必須要早作準備。為了保證資源不成為系統擴容的阻力。DBA和雲資源團隊進行合理規劃，短期內透過借用集團上雲的機器，同時縮容其他BU資料庫叢集，湊出400臺左右的機器，保證高優先順序系統的擴容需求，同時協調雲資源進行搬遷，在短短几天內搬遷了300多臺機器到釘釘資源池，保證了釘釘所有資料庫的擴容需求。資源到位後就是檢驗資料庫彈性的時候了，依託於PolarDB-X 三節點分散式的部署架構，我們可以較為方便的對原有叢集進行線上升級和擴容，對使用者影響很低，並保證資料的一致性。有些場景使用者需要從原有叢集將資料遷移到分庫分表更多的新叢集，我們利用DTS搭配成熟的管控平臺也能較為流暢的完成。最終我們可以做到只要有資源，資料庫也能具有極致的彈性，滿足業務需求。在系統高峰來臨之前，資料庫團隊內部已經準備好緊急預案：引數降級，調整資料庫引數充分發揮資料庫能力，提高吞吐
資源降級，調整資源限制，CPU隔離放開及資料庫BP大小緊急上調
針對異常SQL，確認影響後緊急限流，或者 透過SQL Execute Plan Profile 進行緊急干預
全叢集流量備庫分流，依據壓力情況最大可 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的一種通用的單鏈路壓測能力，並不依賴上游業務，DB層可以自己進行流量的生成，放大或縮小，甚至將事務比例更改後再次壓測的能力。從2019年開始，在DBA和達摩院資料庫實驗室科學家們共同的努力下，我們開發了ClouDBench實現了上述的需求，並在此次的戰役中幫助DBA進行容量的評估。
藍色是真實業務在某個時刻的效能曲線，綠色是我們採集DB端流量回放出來的效能曲線，可以看出兩條曲線在時序上高度擬合，特別是InnoDB內部的指標都非常接近，包括流量的波動。當我們能夠比較真實的回放出業務的workload，我們即可以對壓力進行放大，以此來分析DB的容量，並分析出極限場景下的效能瓶頸，從而進行DB的最佳化及驗證最佳化效果。ClouDBench目前已經在共有云資料庫自治服務Database Autonomy Service(DAS)中灰度上線，我們會在後續的文章中詳細介紹下ClouDBench的實現，敬請期待。成果及思考
在2月17號第三波高峰時，釘釘各系統穩定執行，2月18號開始，我們從之前的全員重保變成日常維護，為什麼我們有這個信心，因為我們對所有系統的資料庫都進行了擴容和最佳化，具有遠超當前系統容量的能力。短短兩週內各資料庫系統具備了數倍到40倍以上的能力，其中不乏超大型資料庫叢集，儲存空間超過1PB。所有這些都充分證明了阿里雲資料庫的彈效能力，透過管控/DTS/CORONA各產品的完美配合，使阿里雲資料庫在疫情洪峰流量面前戰無不勝。此次疫情帶來的爆發式流量對我們來說是毫無防備的，經歷過此役，我們學會了很多，如果再次面臨這樣的問題，我們將遊刃有餘。經驗總結下來有以下幾點：1、人員組織：
首先在人員組織上，業務和開發要對突發流量具備明銳的嗅覺，及時發現提早準備，由業務方穩定性負責人成立應急小組，梳理依賴業務以及對應後臺系統，將各業務線owner和後臺資料庫產品owner納入應急小組。由應急小組統一容量規劃、人力配備以及資源協調，實現業務方/後臺產品團隊/資源團隊聯動。2、技術架構：
在技術架構上，一方面是要使用具有足夠彈性的資料庫產品，保證使用的資料庫產品有自由擴容和縮容的能力，既要保證流量來了之後能擴上去，也要保證日常流量時可以縮下來。管控等各個運維元件需要在實現自動化運維的同時，對於很多關鍵操作留有應急開關，確保在一些極端場景下，可以較方便的從自動駕駛切換成手動模式，確保任務平穩高效的執行下去。3、應急手段：
在面對系統瓶勁時，在業務上和資料庫產品上都要提前做好預案，在業務上要有降級和限流功能，在系統無法承受壓力時，可以降級一部分非核心功能，限制一些次核心功能來保核心業務的正常執行。在資料庫產品上需要具有在不擴容的情況下，透過一些最佳化手段瞬間提升資料庫吞吐的能力，更重要的是這些能力需要有較好的相容性，在不同的部署環境，不同的DB架構下都具有相應的工具和預案。另一方面，我們需要有評估和檢測預案效果的手段，我們現在可以利用ClouDBench對DB進行容量的分析和預測，但是當前的使用成本還是過高，後續ClouDBench需要更加自動化，降低使用成本，將能力透傳給業務的owner，在大促之前，自動進行大量的DB單鏈路壓測，評估系統水位，發現效能瓶頸，最佳化DB引數，驗證預案效果。最後祝福釘三多在阿里雲資料庫的支撐下飛的更高飛的更遠！
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69940574/viewspace-2682656/，如需轉載，請註明出處，否則將追究法律責任。
