記一次公司專案快取擊穿

我們先說業務問題，該專案是乙個微服務專案，邏輯是a服務啟動後會把自己的乙個業務資料放到redis快取服務中，然後b服務的乙個介面就會去從redis快取服務去獲取這個資料然後和自己的資料庫業務資料關聯，處理返回給客戶端。

正常情況下我們的業務處理步驟。

## 連線redis伺服器獲取資料 ## 開啟資料庫連線 ## 查詢資料 ## 關閉資料庫 ## 記憶體業務處理

## 返回

但是當我們將我們加入工作單元然後將工作單元aop到介面層,我們的步驟就會改變。

## aop開啟資料庫連線 ## 連線redis伺服器獲取資料 ## 開啟資料庫連線 ## 查詢資料 ## 記憶體業務處理 ## 返回

## aop關閉資料庫

這個時候如果我們的redis快取伺服器宕機了，好玩的事情就來了，我們批量設定的快取伺服器超時是5秒過期我們會從a服務的業務介面去拿資料，但是這個介面的業務併發量如果在每秒鐘2w,那麼從第乙個請求進來開啟資料庫連線，

到第乙個請求的資料庫連線被關閉，理想情況這裡要經過5+1+1，也就是14w個占用，但是資料庫連線是非常占用記憶體的，在還不到14w個連線的時候伺服器的記憶體和cpu就會被吃滿，滿了之後你的業務服務就會因為沒有資源使用而崩潰掉。

解決方案也比較簡單，正常我們使用的框架比如abp vnext，我們可以在介面定義預設不開啟工作單元，然後我們在業務部分手動去開。

那麼這個事情為什麼是細思極恐呢，因為我們正常微服務請求，採用aop開啟工作單元，我們業務部分請求多個串聯的伺服器介面，某一環節介面宕機，在加上我們的重試機制，這個業務時間是要超過7秒的，在高併發的請求下就會出問題