趕考狀元：如何快速應對數據庫QPS暴漲20倍？咱們作了三次決策

受疫情影響，全國各學校的開學均被延期。爲避免耽誤學生的課業，教育部推出了「停課不停學」政策，鼓勵師生積極開展線上教學模式。

趕考狀元（上海億山睦教育科技有限公司）爲此積極響應政府號召，向湖北全省一年級到高三的學子免費開放教材的同步在線教學課程，後來進一步擴大至全國範圍。這一公益活動得到了很大反響，網站用戶註冊量和瀏覽量超過平時數倍。

雖然活動從策劃到上線總共只有4天時間，趕考網技術團隊經過科學決策，及時精密的實施，完成了業務代碼改造、架構評估、擴容升級、SQL優化等工做，期間也和UCloud UDB團隊緊密合做，在其協助下實現了數據庫的架構改造和擴容，很好地承接了QPS暴漲20倍的訪問壓力，圓滿完成技術保障任務。

下面分享一些咱們在此過程當中的細節和思考，供有快速擴容須要的企業參考。

面臨的業務痛點

公司自2005年成立一直專一於K12在線教育，這次疫情公益活動構想階段，業務側運用此前超過十年的互聯網及線下教育經驗，快速設計了有效可行的方案，在很多細節上下了功夫，例如加速審覈通道，只需兩步便可學習的易用性，面向家長推廣的二維碼等。

技術團隊的任務則是提早預判後臺流量的迅猛增加，未雨綢繆設計行之有效的預案，查漏補缺，切實保障活動順利流暢運行。爲此咱們細緻梳理了現有架構的薄弱點，並相應制定了精準有效的擴容方案。

因爲咱們原先的擴容是穩定慢節奏的，此次預見到了大量訪問需求，首要工做是分析現有架構的能力和不足。

此前業務的主應用架構爲ULB負載+雙UHost單體架構+分佈式緩存+單實例高可用UDB，用了大量UCloud的雲組件。咱們全面梳理了架構各層模塊，對每一層的能力作了評估。ULB有扛大流量的能力，主要關注後端。UHost上是應用服務，咱們測算了一個部署於8核16GB UHost上的主站模塊可以扛住多大併發請求、應用模塊垂直擴容和平行擴容兩個方案的優劣對比，最終決定水平擴展。考慮到外圍的單體服務接口受主應用流量的帶動，也進行了擴容承壓的調整。緩存的作法是加大分佈式緩存、優化訪問緩存。壓力最大的是數據庫，可能帶來性能上的嚴重瓶頸。

不論是MySQL、PostgreSQL仍是MongoDB，咱們都採用了UCloud 的 UDB 託管服務，其中包括核心數據庫。相比自建數據庫，UDB提供的高健壯高可用以及免維護的服務，可讓咱們更安心專一於上層業務邏輯的構建上。且在數據的安全問題上，UDB提供了完善的備份和恢復機制，避免數據意外丟失。

快速擴容的三次決策

一、在線垂直升級

最初咱們的業務核心數據庫選用了高可用UDB部署。在業務平穩期，從性價比角度考慮，最開始UDB實例配置不高，預估QPS最大負載在3000之內。業務爆發前夜，首先對UDB實例作了垂直升級，大幅度提高了數據庫的內存和磁盤配置。這個操做很快，幾乎不影響業務訪問（只在磁盤升級時有秒級訪問中斷）， 實例的處理性能迅速獲得提高。

二、高性能讀寫分離 

但高速增加的業務，給數據庫帶來的壓力預計很快便超過單個UDB實例所能承受的極限，所以數據庫從單機升級爲集羣勢在必行。

咱們設計方案時，得到了UDB團隊的協助。分析業務的SQL請求後，發現讀寫比例在50 : 1左右，屬於典型的讀多寫少業務，因而向咱們推薦了一主多從 + 讀寫分離Proxy 的數據庫集羣架構。

在該架構下，主（高可用UDB）和從（單節點UDB）之間經過異步複製保持數據同步，業務數據庫IP改指向讀寫分離Proxy的IP，由讀寫分離Proxy識別業務SQL的讀寫類型，將寫SQL、事務讀SQL轉發到主， 普通讀SQL按比例轉發到從，轉發比例控制檯可自由配置。同時，讀寫分離Proxy幾乎100%兼容MySQL語法和協議，業務無需改造便可順暢接入。

經過該架構，彷佛可完美解決讀多寫少業務對數據庫的大流量壓力問題，但實際上仍有一些相當重要的技術細節須要把握。 

其中之一就是讀寫分離中間件的轉發性能問題。從理論上看，能夠經過橫向添加從節點的辦法線性提高數據庫集羣的讀性能，但若是底層從節點數量加上去了，讀寫分離中間件又是否會成爲新的瓶頸？ 

咱們十分重視這個問題，爲此首先作了一系列的數據指標估算，包括現有UDB實例的性能上限、UDB在垂直升級後根據現有訪問模型估算性能上限、UDB升級爲讀寫分離主從集羣后對讀寫請求的處理性能和從節點數量的關係等。

第二步則是和UDB團隊配合作了讀寫分離Proxy的壓測。

上述壓測實驗採用Sysbench程序，在兩臺物理機上模擬了底層UDB節點從1主線性增加到1主6從的狀況下，整個讀寫分離集羣的讀處理性能。從結果能夠看出，得益於讀寫分離Proxy對多核CPU的充分利用，以及代碼層面的多個性能調優， 讀寫分離Proxy具有可靠的轉發性能，不構成集羣的性能瓶頸。從而保證集羣的讀性能，可以隨着從節點的線性增加，呈現幾乎完美的線性增加。

實測數據使人放心，UDB團隊繼而幫助制定了整套UDB擴容計劃，咱們的業務代碼也相應作了調整，整個方案能夠在網站用戶幾乎零感知的狀況下實施。此後，咱們後端服務的擴容有條不紊地開始，天天凌晨在業務低谷時執行擴容，先擴容主站應用集羣，將數據庫升級到讀寫分離集羣，而後逐層向外擴容外圍單體服務，整個擴容工做設計合理，馬不停蹄實施到位。

運營狀況

公益項目開始後，2月1號到2月10號短短10天內，趕考狀元平均日註冊用戶量由0.83萬上升到3萬，最大單日註冊用戶達5.8萬。平穩承壓了單日20萬用戶的web/App訪問，順利地爲全國各地區超過100萬學生免費贈送了在線微課學習、題庫練習、做業組等線上服務，爲停課不停學「添磚加瓦」，貢獻了優質的公益教育資源。

在此期間，咱們業務數據庫的吞吐量（QPS）暴漲了近20倍，目前線上讀寫分離Proxy單實例最高QPS已達到20萬以上，升級到讀寫分離集羣后，經過1主6從加2節點雙活讀寫分離Proxy的集羣配置，平穩扛住了業務流量的高速增加。咱們的技術架構，也成長爲一個具備至關規模的中型互聯網服務。

三、高可用新架構：擴充鏈接數 

在渡過2月10號這個線上開學高峯後，業務依然在高速發展，雖然主從讀寫分離集羣在應對業務高QPS訪問上不成問題，但隨着業務模塊的增多，在2月12號上午高峯期業務向數據庫發起的鏈接數，已經達到高可用版UDB產品6000的上限。

爲了從根本上解決這個問題，UDB研發團隊建議，將高可用UDB的後臺架構，從傳統的VIP+代理+DB 的架構升級爲其最新開發的漂移 VIP+DB 雙主新架構。爲此他們連夜制定了透明升級的方案，可以不遷數據在2分鐘內從舊架構原地升級爲新架構，得到咱們承認並在凌晨實施，確保次日業務的正常運行。

新的高可用UDB架構，利用穩定的UCloud虛擬網絡VIP管理服務，將架構簡化爲更樸素的漂移 VIP+DB 雙主的實現，在數據鏈路上減小一次轉發，消除一個潛在性能瓶頸，而且簡化控制模塊，減小不可控因素。同時新架構對數據庫（MySQL 和 PG）原生的兼容度更高。

慢查詢優化

提早規劃和快速擴容，給了咱們更多的餘裕，能去快速應對和解決大流量突發時暴露的其它隱藏問題，最典型的例子是數據庫慢查詢。

咱們後臺代碼採用了ORM框架鏈接MySQL，因爲ORM層屏蔽了底層MySQL庫表的細節，小部分訪問MySQL的代碼沒有考慮到底層MySQL的執行邏輯，存在慢查詢過多的問題。慢查詢的問題，在平時小流量慢增加的狀況下影響並不明顯，可是疫情期間大流量壓力下就變得不容忽視。

UCloud DBA團隊期間提供了諸多幫助，他們在慢查詢問題的定位和解決上有豐富的經驗。疫情期間，他們克服在家辦公幹擾多,遠程溝通不便等不利因素，經過微信、遠程會議等方法隨時和咱們保持聯繫，結合咱們對業務邏輯的理解，協同定位問題，一塊兒梳理了業務近半年全部新增數據庫表並增長索引，最終慢查詢的問題獲得有效解決。

寫在最後

此次面對突發需求的快速響應擴容，從方案到實施，是雲的使用者和雲廠商分工協做、發揮各自優點的一個有效實踐。咱們在業務中普遍使用UDB，是對於其彈性和全託管這兩個核心能力的充分承認。這次協做，也對其快速應對、方案制定、7*24在線服務等有了更多認識。

據悉，近期UCloud UDB團隊還將推出快傑UDB新產品，其基於計算和存儲分離架構構建，並結合UCloud數據方舟後端的分層混合存儲設計，可實現數據庫數據的快速備份和恢復到任一秒能力，有效避免用戶誤刪數據庫致使數據丟失以及數據恢復慢等問題，值得期待。