一直以來我們認(rèn)為 Redis 是單線程的，單線程為 Redis 帶來了代碼的簡潔性和豐富多樣的數(shù)據(jù)結(jié)構(gòu)。不過Redis內(nèi)部實(shí)際上并不是只有一個(gè)主線程，它還有幾個(gè)異步線程專門用來處理一些耗時(shí)的操作。

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

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

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

> unlink key OK

如果有多線程的開發(fā)經(jīng)驗(yàn)，你肯定會擔(dān)心這里的線程安全問題，會不會出現(xiàn)多個(gè)線程同時(shí)并發(fā)修改數(shù)據(jù)結(jié)構(gòu)的情況存在。

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

flush

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

> flushall async OK

異步隊(duì)列

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

?

?

?

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

AOF Sync也很慢

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

更多異步刪除點(diǎn)

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

Redis4.0 為這些刪除點(diǎn)也帶來了異步刪除機(jī)制，打開這些點(diǎn)需要額外的配置選項(xiàng)。

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

lazyfree-lazy-eviction?內(nèi)存達(dá)到 maxmemory 時(shí)進(jìn)行淘汰

lazyfree-lazy-expire key?過期刪除

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。