乾貨|上雲了，如何保障雲數據庫的高可用？

 

責任共擔模型

朋友和我吐槽，自從他負責的系統上雲後，在雲數據庫上經歷了好幾回故障，而過後的故障覆盤，竟然都是他們本身的責任和問題，這讓他很被動。更尷尬的是，原想着上雲後，數據庫的問題都是公有云廠商負責，因此他們運維團隊中也沒有招聘DBA，當下沒有很好的優化思路，因而找我一塊兒探討這個問題。

朋友的這個Case很典型，認爲上雲就萬事大吉，上雲後一旦出現問題，又會以爲上雲各類不靠譜。在公有云廠商中，被你們廣爲承認的觀點是「責任共擔模型「。在海外，亞馬遜AWS、微軟Azure均採用了與用戶共擔風險的安全策略。例如，AWS 做爲IaaS+PaaS爲主的服務提供商，負責管理雲自己的安全，業務系統安全則由客戶負責。客戶能夠在AWS安全市場裏挑選合適的產品來保護本身的內容、平臺、應用程序、系統和網絡安全。而微軟Azure也探討了IaaS, PaaS和SaaS用戶的「責任遞減」模式。在這裏，咱們並不打算展開討論該問題，只是但願引入該概念，讓你們創建初步的認知：上雲後，依然是須要客戶和平臺雙方通力合做才能取得好的結果。

 

上雲後他經歷了什麼？

下面是朋友講述的故障，限於故障緣由的重複，我刪減了一些Case，聽朋友講完後，我很是吃驚，內心暗想，這和上雲有啥關係，這些問題，你不上雲照樣都會發生的，只能說你運氣好，發生在上雲期間，你們對於新事物多少有一些寬容，否則，後果不敢想啊。

• 後端模塊批量重啓，重啓時須要從數據庫加載業務數據，因併發重啓且該請求爲慢SQL（幾十秒），雲數據庫負載快速升高，部分請求開始超時，而後請求失敗的模塊無限重試，致使雲數據庫負載過大而崩潰，依賴該數據庫的其餘業務也所有故障；
• 在短期大量併發請求數據庫，高峯期併發達到2200左右，致使數據庫出現大量慢SQL，進而數據庫性能急劇降低，多個業務頁面展示變慢，性能退化明顯；
• 批量建立的任務，其執行時間徹底一致，系統在瞬間對數據庫請求大量數據，鏈接數上漲，致使該數據庫上的全部業務均發生故障；
• 一次秒殺活動，系統請求量劇增，峯值流量達到平時流量的30倍，遠超以前預估流量。部分功能大量請求數據庫，佔滿數據庫連接，致使數據庫崩潰，進而引發系統沒法正常運行；
• 其購買的安全掃描產品，對接口進行了空參數請求，而接口對於空參數請求進行了數據庫的全表掃描，數據庫壓力飆升，陸續出現了慢SQL，數據庫CPU使用率持續在100%，致使該數據庫上的其餘業務也所有故障；
• 某服務訪問數據庫錯誤致使響應下游請求合法用戶列表的結果爲空值，下游模塊直接將全部用戶的權限所有刪除，致使系統徹底不可用；
• 沒有專職DBA，雲數據庫的變動直接交由研發本身執行，研發屢次數據庫修改出現異常，致使服務故障和數據丟失；
• 研發懷疑數據庫性能惡化，所以就重啓了數據庫，重啓期間，有一個模塊請求數據庫失敗，就直接崩潰了；
• 在華南部署的一套業務系統，連到華北的數據庫，致使系統的響應時間長期居高不下，緣由是一個頁面包含了很是多的數據庫請求，單個請求延時增長40ms，但幾十個請求串行執行，延時足足增長了2s以上。

 

故障緣由分析

和京東雲平臺質量部的同窗們對上述的Case進行分析後，咱們總結了如下緣由：

慢SQL

常態下系統中存在不少慢SQL，其執行時間少則15s，多則60s以上，若是慢SQL的執行次數增長，必然致使雲數據庫壓力上升，數據庫鏈接被佔用，處理其餘請求的速率也慢了下來，直至鏈接數被耗光，致使服務異常，或者在鏈接數沒耗光以前，就由於數據庫CPU使用率100%而致使服務異常了。

高頻SQL

高頻SQL看似沒有問題，但延時一旦增長或者網絡抖動，高頻SQL就可能變爲較慢的SQL，基於其基礎足夠大，足以將系統拖垮。

複用

上面的屢次故障都是由於某一個業務異常致使數據庫故障後，影響到了數據庫上的全部業務，這多是源於指望下降運維複雜度，因此搞了一個最大規格數據庫的緣由，確實，全部業務共用一個數據庫從管理角度確定更簡單。

讀寫未分離

上述的Case，大部分都是讀請求致使的故障，忽然間由於各類緣由，致使請求上漲，而數據庫實例只有一個，沒有水平擴展，因此很容易被打掛。

數據庫鏈接數設置不合理

從故障描述中能夠看到，隨便一個請求，均可以把數據庫的併發鏈接數打到2000+以上，進而致使其餘業務不可用，沒有對不一樣業務進行合理的資源分配。

缺少變動流程

研發直接到線上數據庫中修改數據，修改錯誤的緣由有表的名字錯了，where條件錯了，或者是對較大的表結構進行調整，操做前不在線下進行測試驗證，操做前也不進行數據庫備份，很容易致使重大事故。

權限管理混亂

多個CASE都是研發直接操做線上數據，這是權限管理混亂的表現，也是很危險的事情。試想，人人都能修改數據庫，會有什麼後果你們應該都很清楚。若是修改了和交易數據相關的數據，或者是刪庫跑路，那就麻煩了。

不限流

多個CASE也都看到這個問題，全部的接口都沒有作限流，你們能夠發起隨意量級的訪問，所以隨便一個用戶發起批量請求都足以將系統打垮。

 

雲平臺質量部的建議

結合該朋友的狀況，雲平臺質量部的同窗通過討論後，對數據庫的改進給出以下建議，而對於一些較爲通用的問題，如系統異常後直接崩潰，空參數等等，則不在此進行討論，咱們後續會有專門的文章進行說明

TOP-N的SQL限流

TOP-N的SQL分爲兩種情形：

• 慢SQL，也就是執行耗時的TOP-N
  • SQL優化
  • 合理設置數據庫鏈接數
  • 執行耗時超過1s的SQL直接kill（對於部分場景能夠進行自定義，如同步任務，寫SQL，重要性較高的SQL等）
  • SQL問題較多的帳號進行緊急封禁
• 高頻SQL，也就是執行頻次的TOP-N
  • 經過業務層的緩存功能減小高頻SQL

在京東雲上，提供了性能優化的功能，能夠查詢到全部的慢SQL，必定要加以使用

最後提一句，必定要想辦法在集羣上實現自動化kill慢SQL的功能，而不要等遇到出問題後挨個找人來看能不能殺這些SQL，那就太晚了，經驗值，一旦走到這個地步，故障時長起步40分鐘。

隔離部署

核心業務必須使用獨立的數據庫實例，僅非核心業務能夠考慮共用數據庫實例。從而避免單個用戶的問題影響到全部業務。但隔離不只僅是基於業務角度進行隔離，還能夠根據業務狀況進行其餘維度的隔離，例如將一些報表類業務從核心業務中剝離出來，相似的思路，業務運維的隔離方式有不少，能夠參考《任務調度系統如何經過隔離提高可用性？》

從成本角度看，京東雲很好的考慮到了這點，兩個小實例的價格等於一個大實例的價格，所以拆分並不會增長費用，而管理成本的增長也很是低。

讀寫分離

京東雲的雲數據庫提供只讀實例，須要利用好該特性。簡單點就是新增幾個只讀實例將讀請求進行遷移，複雜點，能夠將不一樣業務類型的讀請求分配到不一樣的只讀實例上，利用隔離的特性將故障控制在較小的範圍內，從而保障大部分功能的正常使用。

限流

限流不只僅在數據庫層面經過鏈接數的方式進行控制，更須要前置在業務側進行，畢竟業務側的限流機制會更爲靈活和定製化，更能知足業務的需求。如何限流，能夠參考《預案三板斧的限流大法》。

數據備份

對數據庫的任何修改和調整，都須要進行備份，以避免發生上述朋友的問題。京東雲提供了靈活的數據庫備份管理功能，須要好好的使用起來。這個地方的重要性，就不贅述了。

數據庫的監控

沒上雲以前，可能會有專門的DBA團隊來對數據庫進行監控，上雲後，若是沒有專職的DBA，那麼業務運維團隊就須要承擔起這個責任來。下面是從京東雲的監控中截取的幾個關鍵指標，固然，還須要有對數據庫功能的監控。在這點上，雲平臺質量部有較爲豐富的經驗，你們也能夠參考《監控不到位，宕機兩行淚》。

流程創建

對於變動和權限管理等，都須要逐步創建起相關的流程，並儘可能自動化起來。同時，針對各類高頻操做，還能夠提供如操做手冊，checklist手冊等，儘可能減小手工操做。

 

三板斧

我我的的習慣，任何問題，提供了多個解決方案後，最後都要經過三板斧來進行優先級排序，便於你們抓住重點：

• 隔離部署&&讀寫分離，利用京東雲的能力，能夠快速搞定，因此放第一位；
• TOP-N的SQL，找出來容易，優化則須要研發配合，所以放第二位，能夠先從那些執行時間幾十秒的SQL開始下手；
• 限流，或者在接入層進行，或者核心模塊上進行開發，耗時略長，所以放第三位。

最後，感謝平臺質量部的多個小夥伴一塊兒羣策羣力完成的上述方案。

 

---

 

參考文獻：

任務調度系統如何經過隔離提高可用 https://www.infoq.cn/article/vsb2jGCAgXPPdqPS38S6

預案三板斧的限流大法 https://www.infoq.cn/article/L1FThcLIgzHSYlIaDk0R

監控不到位，宕機兩行淚 https://www.infoq.cn/article/txmNQW_d7Hpi8KyXf4wz

責任共擔模型 https://aws.amazon.com/cn/compliance/shared-responsibility-model/

 

---

 

點擊「連接」瞭解雲數據庫 SQL Server更多詳情！

歡迎點擊「京東雲」瞭解更多精彩內容。