問題描述：

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

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

問題復(fù)現(xiàn)：

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

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

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

問題排查：

檢查和token相關(guān)的一系列配置，查看是否配置問題

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

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

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

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

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

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

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

確認(rèn)原因

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

查了下有什么大key或者熱key占用了這么多的內(nèi)存

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

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

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

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

為什么

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

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

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

所有的策略如下

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

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

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

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

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

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

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

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

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

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

最新評論