2016阿里雲資料庫雙11覆盤-自動化備戰，0干預

前言

2016年天貓雙11購物狂歡節已經完美落下帷幕，高峰期間訂單建立每秒達到了16.5萬筆，RDS叢集的QPS最高達到了400W，其中99%的商家訂單在阿里云云資料庫服務中完成儲存和處理。這是RDS連續第五年支援天貓雙11大促，在持續高壓力衝擊下，整個雙11期0故障0丟單，相比前面四年，我們在備戰過程中更加的自動和主動，今年雙11高峰期間做達到了0干預的目標。這些都是在前期充分的準備工作中所換來的從容，在面對這麼大規模例項備戰的時候，通過前幾年備戰經驗的積累，我們在產品自動化上繼續深挖，主動推送彈性升級，主動對例項進行健康診斷，主動對叢集資源遷移離散，秒級監控大盤等等，通過系統和平臺將雙11的經驗沉澱，為雙11的穩定平穩渡過奠定了基礎。同時在核心鏈路元件上不斷深入優化，用效能的提升達到了成本的節約。下面分享一下今年雙11 備戰過程中我們在自動化以及效能優化所作的一些改進。

專家系統主動健康診斷—一千個“DBA”在幫使用者

在前面四年雙11保障過程中我們發現雙11當天往往最容易出現問題是使用者自身的應用程式問題導致系統卡慢。雙11前沒有暴露出的問題，會由於雙11當天巨量的訂單和高頻的系統呼叫將這些潛在問題放大。提前找出並解決問題是保障雙11穩定執行的最佳手段。因此本次雙11活動之前，我們就對所有相關資料庫進行了全面的體檢，將資料庫中的潛在風險提前識別出來，並通知使用者進行優化和升級。本次雙11備戰期間我們為客戶的例項進行了三輪主動健康診斷，其主要特點：1）診斷報告生成的高度自動化。生成健康診斷報告上萬份且全程無人工干預，這一全新的運維方式在之前是不可想象的；2）診斷內容的深度化。從基本的資源使用情況和慢SQL分析，到死鎖檢測和審計日誌全方位統計，再到事務的深層次分析找出應用中的潛在問題等都包含在我們的診斷報告當中；3）運維保障的人性化。本次雙11保障不是簡單粗暴的讓客戶升級系統規格，而是以優化為主升級為輔的方式。提前主動給出診斷優化建議極大的提升了使用者體驗。

Proxy 效能5W到10W的提升

Proxy作為整個RDS資料通道的咽喉，其穩定性是影響整個雙11能否成功的關鍵因素。今年我們雙11在 proxy的穩定性及可運維上進行了改進，同時在效能優化上通過減少訊息量及資料拷貝使得效能從原來的5w提升到10w，使得在叢集不擴容的情況下，承載了去年2倍的壓力，相當於減少了一半的機器。通過調整核心引數SO_RCVBUF來提高proxy與client的吞吐量，對於前端網路質量較差的情況吞吐量提升10倍以上。另外，在雙11之前通過proxy的容量評估模型發現叢集內各分組的壓力不均衡問題，從而進行遷移保證了在雙11期間各叢集及分組壓力更加均衡。同時對聚石塔叢集的多項重要指標進行秒級大盤化監控，保證能夠快速精確的發現系統的潛在問題及容量風險。

秒級監控大盤

打仗行軍必須要有可靠，準確和及時的情報資訊來支撐瞬息萬變的戰場。在雙11當天，秒級監控大盤能夠幫助我們實時關注系統健康狀態，分組監控大盤幫助我們關注各個戰場執行情況，心中有了運籌於帷幄之中，決勝於千里之外的感覺。
• 每秒更新的叢集QPS、流量、延遲、連線數核心指標；
• 全量觀察所有Proxy節點關鍵指標的健康度，秒級發現健康情況變差的節點；

為了能夠提前發現Proxy的異常並抓住具體的異常點，我們需要在一個頁面上檢視多項關鍵指標在每臺Proxy上的健康狀況，前端設計上通過熱力圖的形式來展示，通過精心選擇的顏色來標示這個指標的健康情況，多個指標通過tab的方式自動切換。
我們首先需要以最低的損耗全量紀錄使用者請求的資訊，我們在核心TCP協議棧狀態機中將每個SQL請求的流量、網路延遲、處理延遲等指標計算出來，並通過記憶體將資料傳到使用者態。為了減少傳送資料的網路損耗, 首先會在本地進行預處理聚合, 壓縮後傳送到Kafka叢集, 後面用JStorm對不同機器來源的資料進行實時分析。
為了前端的流暢，減少渲染開銷，實時趨勢圖只在頁面渲染的時候整條線繪製一次，後面每秒的增量都只做累加繪製；熱力圖也只在頁面渲染的時候才會繪製節點結構，而後面的狀態資料更新也只是更改各節點的顏色屬性，且五個指標資料共用一個節點結構。
我們在各個環節都做了容錯處理，在計算任務上可以出現失敗後補回資料，儲存上使用RDS作為保障，多節點資料API，前端頁面在訪問後端出現問題時仔細的處理了異常，保證瀏覽器頁面不崩潰，並在異常恢復後，補回資料繼續實時更新。

主動推送彈性升級

彈性升級是商家在雙11備戰過程比不可少的一個環節，但是每年還是有很多使用者不知道是否需要對資料庫進行彈性升級。常常看到雙11當天還有較多商家進行升級，這個時候其實已經比較危險了，這個時候系統壓力往往非常大，對彈性升級的任務是有較大影響的。所以在2016年的雙11備戰前期，我們的系統能不能夠針對使用者的系統壓力分析，提前通知使用者進行升級，這樣對雙11的平穩渡過有著重要的意義。今年雙11期間，通過掃描例項資源使用情況推動客戶升級數佔總升級的90%。

移山資源自動打散—讓資源流動起來

底層物理資源的穩定和均衡是保障雙十一穩定執行的基礎，雙十一之前我們自動將叢集的主機根據負載情況進行自動的離散，最大化的利用叢集的計算資源，同時也保障在雙11期間沒有資源使用沒過載的主機出現。雙十一備戰期間，通過系統共下發離散遷移任務超過1000+次，充分有效地利用了線上資源，為雙十一的穩定做出了巨大貢獻。雙11結束之後，移山可以方向進行資源搜尋，將雙11擴容的資源再次回收到資源池中，以供其他業務進行售賣，已達到資源的最大化使用。

Proxy鏈路-防閃斷，防攻擊

然後有人可能會問這些後臺的資源離散任務是如何做到對使用者的訪問實現無影響的？其核心的技術就是在代理層對使用者連線上的處理–proxy防閃斷。通過協議級解析及SQL parse兩層邏輯來判斷使用者的連線請求狀態，對於“空閒”的連線通過proxy來完成切換，連線到新的主庫地址，並且對使用者無感知。對於非空閒比如事務，我們會等待事務結束再進行切換，儘量的減少切換對使用者的連線的影響，通過線上的資料我們行到我們防閃斷橋接率達到93%。

Proxy除了連線防閃斷能力外，還具有防攻擊能力。由於所有的應用請求都經過proxy處理，所以我們在proxy層加入了SQL攔截規則，對於符合注入規則的請求我們可以進行攔截，保護使用者資料庫的安全。

雙11當天問題

通過前期大量的備戰工作準備，雙11高峰期間我們沒有對系統做過任何的干預措施，但收到部分使用者反饋的一些典型問題，下面總結如下：

彈性升級任務時間較長

使用者的彈性升級過程可能有兩類，一類是本機升級，另外一類是跨機升級。本機升級的時間受限於例項本身的壓力，如果資料庫壓力過高可能會導致備庫無法完全與主庫同步，進而導致升級時間較長；跨機升級的時間除了受限於例項自身的壓力外，還與例項的資料量大小相關，具體可以參考文章“高人自有妙計：羅龍九六招制服雲資料庫大流量峰值”。

使用者自身問題導致系統卡慢

雙11期間較多客戶反饋應用不能響應或rt較長，通過排查定位絕大多數情況是資料庫響應請求很快，但是瓶頸在自身的系統設計缺陷以及應用伺服器問題，比如DNS請求訪問緩慢，或者表結構設計不當，索引缺失等問題。
表結構：
order` (
ID int(10) unsigned NOT NULL AUTO_INCREMENT,
No varchar(50) NOT NULL DEFAULT “,
From varchar(50) DEFAULT NULL,
Shop varchar(50) DEFAULT NULL,
Code varchar(50) NOT NULL DEFAULT “,
Flg int(11) DEFAULT `0`,
PRIMARY KEY (ID,No,Code)
) ENGINE=InnoDB AUTO_INCREMENT=176667 DEFAULT CHARSET=utf8
訪問SQL：
update order set Flg = `1`, No = `11` WHERE No = `11` AND Code=`22` and Flg=`0`
優化建議：
alter table order add index ind_orderdetail(No)

雙11的全民化

隨著雙11的全民化，有許多企業公司也開始做雙11促銷，但是他們的經驗往往是比較匱乏的。雙11當天我們就收到了一些使用者的援助請求，由於前期沒有做好系統壓測，導致在雙十一當天業務高峰來臨的時候系統垮掉，然後才考慮擴容，這個時候往往已經為時已晚。雙11的護航保障經驗是可以更廣的傳播到這些公共雲客戶上，這也是為什麼會寫這篇文章的主要原因。

未來，沉澱專家經驗到系統中和傳承保障經驗

雙11是全民的雙11，雲端計算是全民的雲端計算，我們忠心希望未來使用者在使用雲端計算的時候能夠像使用水電煤一樣簡單。我們也會不斷地將最佳實踐和雙11的保障經驗沉澱到專家系統中，只有這樣才能將其作用最大化，規模化，可複製化，讓使用者真正簡單方便的得到實惠。