Redis 全部的數據結構均可以設置過時時間，時間一到，就會自動刪除。你能夠想象 Redis 內部有一個死神，時刻盯着全部設置了過時時間的 key，壽命一到就會當即收割。git
你還能夠進一步站在死神的角度思考，會不會由於同一時間太多的 key 過時，以致於忙不過來。同時由於 Redis 是單線程的，收割的時間也會佔用線程的處理時間，若是收割的太過於繁忙，會不會致使線上讀寫指令出現卡頓。redis
這些問題 Antirez 早就想到了，全部在過時這件事上，Redis 很是當心。算法
過時的 key 集合
redis 會將每一個設置了過時時間的 key 放入到一個獨立的字典中，之後會定時遍歷這個字典來刪除到期的 key。除了定時遍歷以外，它還會使用惰性策略來刪除過時的 key，所謂惰性策略就是在客戶端訪問這個 key 的時候，redis 對 key 的過時時間進行檢查，若是過時了就當即刪除。定時刪除是集中處理，惰性刪除是零散處理。sql
定時掃描策略
Redis 默認會每秒進行十次過時掃描，過時掃描不會遍歷過時字典中全部的 key，而是採用了一種簡單的貪心策略。shell
- 從過時字典中隨機 20 個 key；
刪除這 20 個 key 中已通過期的 key；
若是過時的 key 比率超過 1/4，那就重複步驟 1；
同時，爲了保證過時掃描不會出現循環過分，致使線程卡死現象，算法還增長了掃描時間的上限，默認不會超過 25ms。
設想一個大型的 Redis 實例中全部的 key 在同一時間過時了，會出現怎樣的結果？服務器
毫無疑問，Redis 會持續掃描過時字典 (循環屢次)，直到過時字典中過時的 key 變得稀疏，纔會中止 (循環次數明顯降低)。這就會致使線上讀寫請求出現明顯的卡頓現象。致使這種卡頓的另一種緣由是內存管理器須要頻繁回收內存頁，這也會產生必定的 CPU 消耗。數據結構
當客戶端請求到來時，服務器若是正好進入過時掃描狀態，客戶端的請求將會等待至少 25ms 後纔會進行處理，若是客戶端將超時時間設置的比較短;架構
- 好比 10ms，那麼就會出現大量的連接由於超時而關閉，業務端就會出現不少異常。並且這時你還沒法從 Redis 的 slowlog 中看到慢查詢記錄，由於慢查詢指的是邏輯處理過程慢，不包含等待時間。
因此業務開發人員必定要注意過時時間，若是有大批量的 key 過時，要給過時時間設置一個隨機範圍，而不宜所有在同一時間過時，分散過時處理的...併發
以上內容但願幫助到你們，不少PHPer在進階的時候總會遇到一些問題和瓶頸，業務代碼寫多了沒有方向感，不知道該從那裏入手去提高，對此我整理了一些資料，包括但不限於：分佈式架構、高可擴展、高性能、高併發、服務器性能調優、Redis、Kafka、Mysql優化、shell腳本、Docker、微服務、Nginx等多個知識點高級進階乾貨須要的能夠免費分享給你們分佈式
相應的文章已經整理造成文檔，git掃碼獲取資料看這裏