異常場景

springWeb應用一直運行正常，同事最近反應，每次版本更新完畢，刷新緩存，就會導致應用掛死。只有重啟redis應用才恢復正常。

項目概況

springWeb項目，常用配置表做了redis緩存，配置表中只有少量數據，多也就是1~2K條記錄。用redission做分布式鎖，與緩存用的同一個reids服務。

分析過程

由于系統之前一直穩定運行，只是最近才有問題，先從異常日志查起吧。通過查看tomcat日志，發現大量redis time out異常。起初懷疑是不是網絡原因？但是通過幾次更新，有下午，有晚上，而且如果有網絡問題，其他應用也會有問題。所以排除了網絡原因。

tomcat日志

懷疑redis連接池配置是否有問題，通過查看redission配置，dnsMonitoring參數在低版本的redission中可能導致超時異常。但是通過設置該參數，并未解決問題。鏡頭再回到剛開始，詢問同事，每次都是一操作web端的緩存管理-->清除緩存，系統就掛死。從web端重新開始分析，但是貌似也看不出什么問題。ICacheManager cacheManager = getCacheManager();ICache cache = cacheManager.getICache(cacheName);cache.clear();再統計一下redis中存放的key確實不少，分類統計了下，發現緩存數量與實際表中的配置數量差異比較大。

于是有這樣的假設：清空全部緩存，會先讀出緩存列表，逐個清除，如果緩存比較大就有可能把系統搞死。然后找證據。

通過redisDesktopManager，查看數量最多的key和value，發現緩存的key怎么是對象？value為空的list？

xACxEDx00x05tx00x7FCustomSimpleKey_getSecondTypesCache(class xxx.Param)[{[object Object]=null, timestamp=1589501938332}]

再查看緩存接口，發現緩存失效策略為永久生效。

原來spring緩存接口自動會把接口方法名+參數當作key，db查詢結果當作value緩存。

@ICacheable(cacheSeconds = Constant.FOREVER)public List> getxxxById(String id){return dao.select("conf1", id);}

至此，就可以解釋了。緩存的key隨著入參的不同，會越來越多，而且不會失效。前臺操作清除緩存時，緩存管理器會把所有key讀入內存，逐個清除。由于redis是單線程運行的，在清除緩存的過程中，redis不能對外提供服務，所有用到緩存的地方，請求不到redis連接，就報timeout異常了。

其實這和web端列表展示要分頁是一個道理，如果不分頁，直接從db讀取一個大list，本身就是欠考慮的操作。

解決方案

redis緩存一定要設置失效時間，不要設置成永久生效；

web端清除緩存操作優化

reids監控還是得加上，尤其是這種數量比較大的key，應該增加告警機制

此處可以使用ELKStack中的metricbeat之redis模塊，配合kibana儀表盤展示，一目了然，還可以告警，妥妥的。

總結

以上是生活随笔為你收集整理的redis 清空缓存_「镜头回放」简直了！spring中清除redis缓存导致应用挂死的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。