一次Redis問題排查__Redis

1.問題 2.處理 3.安排 4.分析 5.總結

1.問題

早上發現單體版系統客戶普遍反饋閃退，架構師查看了一下是Redis滿了導致的。登入的session資訊放到了Redis，問題出現在滿了以後，新的登入資訊寫不來。用得是阿里雲的Redis服務，已經做了續約升級，一個月後生效，現在直接做擴容來不及了，試了一下由於前一個訂單已存在，升級失敗。 2.處理

緊急處理，先清空Redis所有資料，這時單體版系統可以登入了，但是發現部分功能無法使用，只恢複了系統80%的可用功能，排查了一下發現是由於一部分的頁面模板也放到了Redis，清空後拿不到模板了。趕緊重啟一下模板項目，寫入到Redis，系統復原。 3.安排

既然出現了緊急的嚴重問題，那麼後續的安排與總結是必須的：
1、安排Team Dev分析問題，把使用方式搞清楚，
2、把上面的緊急處理過程作為一個步驟，寫到wiki上，
3、同時要求添加Redis使用率監控，簡訊通知，
4.分析

Redis使用主從配置，2G，總容量較小，但是考慮之前一直只使用了100多M，所以沒有立即擴容，然後配置了一個月後續約自動加到4G。
從3周前開始，Redis的使用量直線上升。因為沒有做預警，一直沒發現有問題。

單體版和連鎖版共用一個Redis，db0為單體，使用量不大，db1為連鎖有229萬個keys（佔用1.7G），導致使用率太高。
Redis裡的資料有3種：
- 登入session資訊，用來做多台機器間的session共用，有到期時間，單體1天，連鎖30天，
- 頁面模板資料，幾百條，用來渲染頁面，待用資料，不到期，佔用很小；
- 業務Code，操作期間的暫存資料等，這些資料有到期的、有不到期的（業務完成後刪除）。

使用者每一次顯式的登入，都會建立一個新的session id，從而導致在Redis有一個新的記錄，所以單體版裡設定到期時間一天是比較合理的。使用者每天下班關機，第二天上班至少登入一次系統，肯定有至少一次登入（其實遠遠不止，根據統計使用者每次登入平均使用18分鐘，活躍使用者一天可能會登入5-10次）。 5.總結

根據觀察發現，基本每天登陸資訊的key增長約為8萬，一個月才到期導致最終出現問題。
這說明我們對緩衝的使用缺乏必要的指導原則，容量預期和監控手段。
1、監控預警：設定使用超過90%做預警通知，通知架構組和開發人員。
2、設計原則：原則上Redis上的資料必須有到期時間，除了不會變動的待用資料（模板等）外，其他資料每加入一條沒有到期時間的，都會造成資源減少，時間長了再說資源也不夠用，所以一定要設定到期時間。對於登入session資訊，一天足夠了。對於暫存等臨時資料，2-3天足夠了。一個表單，客戶輸入一半，2天還不處理，肯定對他不重要，3天不處理，客戶自己都忘記了，清空資料對客戶影響不大。如果必須要長期儲存，考慮入MongoDB或MySQL這種可以落地的儲存即可。
3、緊急策略：制定緊急處理策略，清空連鎖的db1資料操作步驟。
4、容量策略：每次上線一個需要使用緩衝資源的功能，需要預估使用的容量，好提前安排擴容。
5、隔離策略：對於不同應用，不同用途的快取資料，應該使用不同的Redis執行個體，避免系統相互幹擾。
6、到期策略：調整Redis超過最大記憶體時的到期策略，從LRU+到期時間，改成LRU，這樣記憶體滿了以後，會先討論近期沒有使用過的冷資料。從而達到不影響業務的目的。