前言

昨晚救火到兩三點，早上七點多醒來，朦朧中醒來發現電腦還開著，趕緊爬起來看昨晚執行的SQL命令結果。由於昨晚升級了阿里雲的RDS，等了將近兩個小時 還在 升降級中，早上阿里雲那邊回復升級過程中出現異常，正在加緊處理。。。有點蛋疼

這個項目主要分為WEB、WEB-Manager、WEB-API、APP（ANDROID、IOS） 。

開發語言主要是ASP.NET

資料庫MySql

架構採用了ASP.NET +EF+ORM Unity依賴注入 採用了DDD的部分實踐

ORM使用的是AutoMapper

使用了Redis緩存

Log4net記錄文件日誌，剛開始使用Mongodb記錄日誌，用了一段時候後取消了。

WEB端使用了angularjs

API層通過JSON數據與APP進行交互，用戶狀態通過access_token進行傳遞

資料庫層目前是基於倉儲（Repositor）模式實現的

剛開始項目急於上線多數採用Linq +lambda 的查詢方式，在實踐過程中發現變態的業務調整和快速的請求響應，將其複雜的查詢改成了原生SQL，通過Context.DataBase.SqlQuery 執行

其他的技術就不一一介紹了

目前訪問量較大的是APP端， 最大並發 1300+

主要是API的壓力比較大，日均 100W+ 請求，API 目前 部署在Windwos server 2012上， 介面在50個以上

資料庫使用的是阿里雲的單機MySql RDS 5.6 版本，10盒12G，連接數2000，iops 6000

目前 單表最大是8000W+數據。物理文件300G，APIlog日均100W+，API與業務系統完全獨立，除了DBLog日誌還有Log4g.net生成的文件日誌。

目前採用的是阿里雲的負載，一主一從 購買的阿里雲負載 兩台應用均為 8盒16G ，10M帶寬 ，資源文件上了CDN。

主的上面部署了WEB端和WEB管理後台，從的上面只有API。

最近用戶量突破10+以上，最大並發1300+ 從前天晚上開始資料庫CPU居高不下，一時達到100%臨界點，導致很多SQL命令執行發生錯誤，鏈接拒絕。阿里雲的報警簡訊也隨之而來，隨即我停掉了IIS應用，因為不停止應用MySql資料庫很難復甦，大概過了5分鐘之後資料庫恢復正常，然後再開啟IIS應用。蛋疼的是阿里雲的負載健康檢查也提示異常，但有點不解的是健康狀態顯示異常，請求仍然在繼續分發，很是不解。立馬我將IIS 應用程序池資源回收，停止然後再重啟，這裡給個提示 重啟IIS應用程序池的時候最好先停止掉IIS應用，然後再重啟IIS應用程序池，不然訪問量大的情況下很難起起來。過了幾分鐘之後負載上的健康檢查顯示正常。

上阿里雲後來看了下各個監控指標，顯示流量從前一個小時開始 突然猛增，我以為是有攻擊，但跟蹤了幾個連接發現是正常請求，但360的防禦助手顯示確實有幾個攻擊，但那幾個請求根本不足以拉跨資料庫，大概也就幾十個請求， 幾個簡單的 XSS攻擊 這裡貼下：攻擊的數量不是太多，但主要攻擊的內容和參數就這個幾種類型

url/'%22/%3E%3C/script%3E%3Cscript%3Ealert%3C/script%3Eurl/'%22+onmouseover=alert+d='%22

url/matrix_callback.php

url/index.php?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)

後來發現是資料庫遇到危機了，CPU幾度達到了100%，活躍連接數和非活躍連接數都比平時都要高很多。目前資料庫中有一張最大的表超8000W條數據，超300W以上的也有十幾張，是查詢拖垮了資料庫，平時開發的時候我們都是要求查詢類的SQL要求0.03秒之內完成。但涉及到這幾張大表的查詢我們設定到0.5秒之內返回。今天肯定是查過0.5秒了，

我查了下阿里雲控制台的慢SQL日誌，眼下系統運行還稍微正常，就拿那些慢SQL 一個一個的優化，不能立馬發版，也就是不能改寫SQL代碼，只能從索引上進行優化了。就這樣把慢SQL逐一過了一遍，大約有20多個 超2秒執行的，最慢的達到了10秒，最大的解析行數達到了10W行以上，哎 應該是下面的兄弟寫sql不嚴謹，否則不會出現解析行數超10W+的，但兄弟挖的坑 我哭著也要去填。就這樣用explain 調整索引的方式逐一過了一遍，之前通過表空間已經做過一次優化了。

到昨晚又到了高並發的時候，資料庫又報警了，還好只是報警沒有給我crash掉。與客戶那邊溝通下來，決定進行資料庫擴容。現在擴容到了16盒64G 連接數14000 iops16000。

增加了一個應用幾點，現在是一主兩從

應該能撐一段時間了

接下來需要著手上讀寫分離， 針對比較大的表進行拆分，代碼和資料庫繼續優化。盡量做到最優。

再下來著手上分布式 因為架構的演變是根據市場營銷情況而定，不能走太前更不能走到市場的後面

周末比較累 寫的比較簡短，有時間再續

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！