問題描述：

發(fā)版后回歸測試，不定時出現(xiàn)token失效，導致自動退出到登錄界面。

如果操作的人員較多，token失效的就比較快，操作的人員較少token失效的相對較慢。

問題復現(xiàn)：

同一賬號多人操作：很快就會出現(xiàn)token失效

不同賬號多人操作：很快就會出現(xiàn)token失效

單個賬號操作：較長時間出現(xiàn)token失效

問題排查：

檢查和token相關的一系列配置，查看是否配置問題

• token的有效時長：設置的是48小時-----正常
• 是否允許多個登錄：設置允許多方登錄-----正常

token是存儲于redis緩存中的，重新登錄，檢查生成的token是否正常存儲于redis。redis中新生成的token的過期時間是48小時左右，所以可以排除自身到期淘汰的原因。

讓開發(fā)人員檢查代碼中是否有token相關的操作。

都不是這些原因，所有能想到的都已經排除了，真的頭大。

再次讓業(yè)務人員一起操作，然后我也登錄，記錄自己的token ，redis中token信息一切正常，再次退出登錄的時候發(fā)現(xiàn)redis中這個token也消失了。

這時候可以確定 是redis中的token丟失而導致失效，從而退出登錄。

至于為什么會丟失，還是沒有頭緒。

確認原因

然后問了下運維同事，幫忙看看redis有什么特殊的情況，這一看就有結果了：redis內存基本快滿了，而且沒有做預警，大家都不知道。

查了下有什么大key或者熱key占用了這么多的內存

發(fā)現(xiàn)系統(tǒng)中另一個服務占用了redis極大的內存，如下

這個服務是公司基礎架構的服務，里面的功能日志是通過redis模式傳輸?shù)?，然后在讀取redis落庫以達到異步解耦。落庫成功就會刪除redis, 而且有個定時任務負責落庫，刪除redis。而我們因為不了解細節(jié) 沒有啟用這個定時任務(也可以說壓根不知道這玩意的存在)，才導致了這個結果。

為什么就不能設置一個過期時間呢，為什么！

直接讓運維同事刪除這些緩存，然后多人操作系統(tǒng) 再試試是否會出現(xiàn)token失效，結果是一切正常，也不會退出登錄了。

為什么

redis內存不足，為什么會刪除我的數(shù)據(jù)而不是報寫入錯誤呢

這個就和redis的內存淘汰策略有關了, redis默認的淘汰策略是noeviction 不淘汰數(shù)據(jù)，新增或者修改操作拋異常，而我們的環(huán)境設置的是volatile-lru

redis是內存工具，所以在內存快要用完的時候，怎么去取舍已存入的數(shù)據(jù)和即將要存入的數(shù)據(jù)，redis官方提供了8種淘汰策略，配置是maxmemory-policy 。

所有的策略如下

• volatile-lru：在設置過期時間的數(shù)據(jù)中淘汰最少使用的數(shù)據(jù)。

• allkeys-lru：在所有的數(shù)據(jù)中淘汰最少使用的數(shù)據(jù)。

• volatile-lfu：在設置過期時間的數(shù)據(jù)中淘汰使用頻率最低的數(shù)據(jù)。

• allkeys-lfu：在所有的數(shù)據(jù)中淘汰使用使用頻率最低的數(shù)據(jù)。

• volatile-random：在設置過期時間的數(shù)據(jù)中淘汰任意隨機數(shù)據(jù)。

• allkeys-random：在所有的數(shù)據(jù)中隨機淘汰數(shù)據(jù)。

• volatile-ttl：在設置過期時間的數(shù)據(jù)中淘汰最早過期的數(shù)據(jù)。

• noeviction：默認策略，不淘汰數(shù)據(jù)，新增或者修改數(shù)據(jù)會拋異常，但是讀操作正常進行，不受影響

所以對于redis的使用需要小心，避免寫入沒有過期時間的數(shù)據(jù)！即使一定要存入永久數(shù)據(jù)，也要預估數(shù)據(jù)的大小，判斷是否會隨著時間不斷增加！增加內存監(jiān)控，設置報警閾值，提前發(fā)現(xiàn)問題。

到此這篇關于redis中token失效引發(fā)的一次生產事故的文章就介紹到這了,更多相關redis token失效內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論