一直以來我們認為 Redis 是單線程的，單線程為 Redis 帶來了代碼的簡潔性和豐富多樣的數據結構。不過Redis內部實際上并不是只有一個主線程，它還有幾個異步線程專門用來處理一些耗時的操作。

Redis 為什么要懶惰刪除(lazy free)？

刪除指令?del?會直接釋放對象的內存，大部分情況下，這個指令非常快，沒有明顯延遲。不過如果刪除的 key 是一個非常大的對象，比如一個包含了千萬元素的 hash，那么刪除操作就會導致單線程卡頓。

Redis 為了解決這個卡頓問題，在 4.0 版本引入了?unlink?指令，它能對刪除操作進行懶處理，丟給后臺線程來異步回收內存。

> unlink key OK

如果有多線程的開發經驗，你肯定會擔心這里的線程安全問題，會不會出現多個線程同時并發修改數據結構的情況存在。

關于這點，我打個比方。可以將整個 Redis 內存里面所有有效的數據想象成一棵大樹。當?unlink?指令發出時，它只是把大樹中的一個樹枝別斷了，然后扔到旁邊的火堆里焚燒 (異步線程池)。樹枝離開大樹的一瞬間，它就再也無法被主線程中的其它指令訪問到了，因為主線程只會沿著這顆大樹來訪問。

flush

Redis 提供了?flushdb?和?flushall?指令，用來清空數據庫，這也是極其緩慢的操作。Redis 4.0 同樣給這兩個指令也帶來了異步化，在指令后面增加?async?參數就可以將整棵大樹連根拔起，扔給后臺線程慢慢焚燒。

> flushall async OK

異步隊列

主線程將對象的引用從「大樹」中摘除后，會將這個 key 的內存回收操作包裝成一個任務，塞進異步任務隊列，后臺線程會從這個異步隊列中取任務。任務隊列被主線程和異步線程同時操作，所以必須是一個線程安全的隊列。

?

?

?

不是所有的?unlink?操作都會延后處理，如果對應 key 所占用的內存很小，延后處理就沒有必要了，這時候 Redis 會將對應的 key 內存立即回收，跟?del?指令一樣。

AOF Sync也很慢

Redis需要每秒一次(可配置)同步AOF日志到磁盤，確保消息盡量不丟失，需要調用sync函數，這個操作會比較耗時，會導致主線程的效率下降，所以Redis也將這個操作移到異步線程來完成。執行AOF Sync操作的線程是一個獨立的異步線程，和前面的懶惰刪除線程不是一個線程，同樣它也有一個屬于自己的任務隊列，隊列里只用來存放AOF Sync任務。

更多異步刪除點

Redis 回收內存除了?del?指令和?flush?之外，還會存在于在 key 的過期、LRU 淘汰、rename 指令以及從庫全量同步時接受完 rdb 文件后會立即進行的 flush 操作。

Redis4.0 為這些刪除點也帶來了異步刪除機制，打開這些點需要額外的配置選項。

slave-lazy-flush?從庫接受完 rdb 文件后的 flush 操作

lazyfree-lazy-eviction?內存達到 maxmemory 時進行淘汰

lazyfree-lazy-expire key?過期刪除

lazyfree-lazy-server-del?rename 指令刪除 destKey

總結

以上是生活随笔為你收集整理的【Redis】懒惰删除的全部內容，希望文章能夠幫你解決所遇到的問題。

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