記錄一次生產Redis 告警

記錄一次生產Redis 告警

當社會工具人 開始享受完成996的福報,晚上10.30到家開始享受這一天的僅有的自己私人生活,突然手機郵件. 羣裏被瘋狂的@我 把我搞慌了,最近好像沒有發版啊,一直挺穩定的啊,運維組開始刷鍋直接扔圖出來 看下方:–>

從上午的6點開始正常的增長一直在穩定的增長 直到晚上9點才基本穩定下來, TMD 我都到家了,才告訴我 哎!沒有辦法 大佬都在羣裏,應用負責人是我,還好我帶了電腦,這個還是比較難排查的,這個不是代碼的bug

先想想 最近做了什麼, …

哦,這個應用功能比較少,只是給我客戶端提供了一個接口,這個接口是分裝了多個業務方的接口這個比較複雜簡單的說一下 這個暴露一個接口給客戶端(app)使用得到數據在前端展示 . 這個接口的業務 封裝了業務方的數據

1. 實時接口 每次都要調用 實時性比較強 (每個人得到的數據不一樣)

2. 一天調用一次 (每個人得到的數據不一樣)

3. 業務方接口 返回的數據量比較大 也是一天調用一次 (每個人得到的數據不一樣)

4. 一天調用一次 (目前所有人看到數據是一樣的)

   這個接口早就上生產了,但是新版本app 會使用到,新版本好像還是在審覈中,一直卡在App Store中.

   趕緊找運營諮詢 -->

竟然發佈了安卓, ios沒有更新 這個好像也沒有同時我們啊.差不多定位到問題了,趕緊去看一下數據埋點.安卓用戶差不多有70%用戶, 我們用戶日活正常百萬級別的.又看了一下 安卓升級到了最新版本的差不多有50w 用戶.我在去看了一下邏輯, 重點上面2和3 的接口進行了緩存 都是緩存到12點進行定時清除,那這個容量圖穩步增長是有道理的, 在思考了一下這個其實不是太好的, 其實可以緩存4小時後者2小時,因爲我們是做支付app 有大量的用戶的是爲了支付的場景 後面停留的時間不多, 這個是一個可以改造的.

在看了一下生產的日誌,第三個接口 緩存的數據比較大這個返回的是對象進行返回的 這個對象下面包裝了5個List<對象> 每個人都會緩存下來,所以想想 這又是空間的浪費.當時的開發的時候只是爲了快速完成,沒有考慮到.

和運維溝通 等等到12點後看一下容量圖的結果,後面來優化代碼,培訓一下組內 Redis 的設計標準.

最後我們看一下效果

好了先寫到這裏,後面把我組內的redis 的設計規範放出來,謝謝大家