自動SQL限流 - Database Autonomy Service

SQL限流是限制資料庫上執行SQL的並發度，通過限制問題SQL的並發度後，保障資料庫正常響應業務請求，保障大部分的業務正常運轉，即通過小部分業務受損，保障大部分業務正常運行。

背景資訊

隨著技術的發展，尤其是雲資料庫的普及，資料庫系統變得越來越穩定，營運工作也越來越輕鬆，版本升級、執行個體遷移等都可以自動完成，上層業務不會有太大的感知。即使硬體裝置或者網路出現故障，巡檢系統也可以快速遷移、及時重啟，保證服務穩定。但現有的這些手段幾乎都是針對服務端的穩定性保證，來自業務端的異常使用造成的問題還需要人工介入處理，比如業務變化中引入了新的慢SQL，突然湧入的洪峰等。這些業務層面的異常發生時，上述的營運手段幾乎都不能快速處理異常，防止系統崩潰。

問題

流量問題：突發的流量急劇上升，影響正常業務，比如緩衝穿透、異常調用、大促等等，造成原來並發不大的SQL，並發量突然上升。
資料問題：有資料扭曲的SQL，影響正常業務，例如訂單資料中存在大帳號，查詢該帳號的相關SQL拖慢資料庫。
SQL問題：資源消耗型SQL，俗稱為“爛SQL”，影響正常業務，比如新上線SQL調用量特別大，又沒有建立索引，造成整體系統繁忙。

使用者問題

怎麼能夠在異常發生的時候，及時發現異常？
發現異常後，怎麼識別需要限流的SQL？
怎麼提取限流SQL的關鍵字，既能協助業務恢複正常，又保障業務的受損最小？
限流執行後，怎麼快速確認執行的限流操作是正確的？

除了上述的問題，在現實生活中可能還會出現各種特殊情況，比如值班人員聯絡不上、工作人員身邊沒有電腦、資訊太多分析難度大、壓力大緊張操作失誤等。

因此需要儘可能的把異常發現、異常SQL定位、SQL限流、跟蹤/復原的整體流程自動化處理。

說明自動SQL限流的解決方案應運而生，該服務已經在阿里巴巴集團內部運行了2年多，並且在2020年2月在阿里雲上發布，您可以在資料庫自治服務DAS進行體驗和使用。

解讀

整體流程：

監控指標採集：在阿里雲申請的RDS執行個體預設開啟主機和引擎的效能指標採集，包括CPU，IOPS，QPS，活躍會話等，這些即時資料是後續所有分析和處理的基礎。
異常檢測：該模組通過機器學習對執行個體歷史效能資料進行離線訓練獲得相關模型，然後利用該模型對即時指標資料進行異常檢測，相比基於閾值的警示，能夠更及時的發現異常，該部分的內容將在後續的系列文章中進行詳細介紹。
根因定位：該模組會訂閱執行個體上的例外狀況事件，並採集異常時刻的會話資訊，然後結合SQL審計中的全量SQL，performance_schema中的統計資訊進行判斷，找出執行個體異常的原因。我們將根因分為四種情境：
- 阻塞型SQL：DAS會利用即時會話，鎖等待，運行中的事務等進行分析，分析是否存在DDL變更，大事務，鎖等待等情境，同時判斷被影響會話的數量和執行時間，如果影響的會話比較多或者執行時間很長，那這不需要通過限流來解決問題，而是終止異常會話。
- 資源消耗型SQL，俗稱為“爛SQL”：該情境中，可能SQL的並發不大，但是消耗大量的CPU或者IO或者網路資源，並且被持續不斷的被提交。
- 流量型SQL ：大量正常SQL同時在資料庫中運行，觸發資料庫的資源瓶頸，導致即使KV類的查詢SQL的回應時間都出現了異常。
- 其他：暫時還無法歸因到上述三種情境的案例。
自動限流：當發現執行個體存在根因分析中描述的資源消耗型SQL和流量型SQL時，會自動提取SQL特徵，對異常SQL進行限流（使用者授權的情況下觸發）。這裡面最難的問題是怎麼選取SQL的特徵，進行精確限流，而不會出現由於特徵選取錯誤而導致業務全面受損。
特徵選取：如果發現需要限流的異常SQL，下一步就需要確定SQL的特徵，理想的情況是特徵是唯一的，只對識別到的異常SQL進行限流而不影響其它SQL。這裡首先要區分SQL模板限流和SQL文本限流。
- SQL模板限流：SQL模板是指將SQL文本的具體參數抽象化後的文本，這類SQL並發度高都會產生問題且與具體參數無關，對應突增流量，無索引等情境，特徵只需要包含模板特徵即可。
- SQL文本限流：這類限流主要針對資料扭曲的情境，同一類模板的一些SQL執行正常，一些SQL執行異常，特徵中既要包含SQL模板資訊，又要包含具體參數資訊。
對於SQL模板限流，如果SQL中包含模板ID資訊，會優先使用ID類資訊，比如使用資料庫中介軟體根據模板自動產生的SQL ID或者開發人員在SQL模板中添加的HINT資訊。
使用ID的優點是容易保證模板唯一，不會對其它模板的SQL造成影響，缺點是同樣的SQL如果不帶ID資訊（比如通過命令列手動執行），仍然可以執行，不受限流並發度控制。
如果不包含模板ID資訊，那就需要提取文本資訊，在分析過程中通過計算獲得SQL模板。如下所示，SQL1和SQL2計算後分別可以得到模板1和模板2。那我們對模板1進行限流，可以獲得的最全特徵為select～id～name～age～from～students～where~name。
```
/*SQL文本1*/
select id,name,age from students where name='張三';

/*SQL模板1*/
select id,name,age from students where name=?

/*SQL文本2*/
select id,name,age from students where name='張三' and sid='唯一ID';

/*SQL模板2*/
select id,name,age from students where name=? and sid=?
```
使用該特徵進行限流，優點是不管從哪種串連方式發送的SQL，只要滿足該特徵都受限流並發度控制，缺點是存在誤限的可能性，比如模板2包含模板1中的所有特徵。
自動最佳化：當根因分析發現可以最佳化的SQL時，除了發起限流應急處理外，還會將異常SQL發送到自動最佳化模組，自動建立索引，該部分的內容將在後續的系列文章中進行詳細介紹。
跟蹤/復原：自動限流後，持續跟蹤，如果發現限流後，資料庫的負載未降低或者降低的流量和預估出現偏差，自動復原限流操作，並再次啟動根因定位。