問(wèn)題

del 和 unlink 有啥區(qū)別啊？為什么String類型刪除不會(huì)做異步刪除？

彬彬回答

DEL 和 UNLINK 都是同步的釋放 key 對(duì)象，區(qū)別是怎么釋放后面的 value 對(duì)象

DEL 每次都是同步釋放 value 部分，如果 value 很大，例如一個(gè) list 里很多元素，這會(huì)阻塞 Redis 工作線程。

為了規(guī)避這個(gè)問(wèn)題，4.0 里引出了 UNLINK 命令，可以異步釋放 value 對(duì)象，放到一個(gè)子線程中。

這邊需要引出一個(gè)釋放的閾值，見(jiàn)后面解釋。

目前默認(rèn)的閾值是 64，例如只有一個(gè) list 里面含有超過(guò) 64 個(gè)元素，才會(huì)異步釋放，否則也是會(huì)同步釋放不同的數(shù)據(jù)結(jié)構(gòu)的計(jì)算閾值的方式不一樣，不過(guò)大致遵循一個(gè)原則：就是要釋放多少塊內(nèi)存即在小對(duì)象上使用 UNLINK 效果等同于 DEL，也是同步釋放，區(qū)別就是要多走幾個(gè)函數(shù)調(diào)用，例如判斷 list 里需要判斷列表的長(zhǎng)度等

大 value 對(duì)象的釋放是異步的，放在一個(gè)子線程上，小對(duì)象之所以不異步釋放，是因?yàn)楫惒结尫牛骶€程和子線程之間需要做一些同步操作（這是有代價(jià)的），然后小對(duì)象釋放，本身也很快就也不值得進(jìn)行異步釋放，內(nèi)存釋放也更及時(shí)。

即可能異步釋放，實(shí)際上會(huì)比同步釋放更慢，所以作者設(shè)置了個(gè) 64 的經(jīng)驗(yàn)值

所以如果是一個(gè)小對(duì)象，DEL 和 UNLINK 其實(shí)一樣；如果是一個(gè)大對(duì)象，UNLINK 會(huì)更加好。

所以大部分情況下都可以用 UNLINK 代替 DEL，而 Redis 其實(shí)也有個(gè)配置項(xiàng)，可以控制將 DEL 默認(rèn)轉(zhuǎn)換為 UNLINK（實(shí)現(xiàn)上都是同一個(gè)函數(shù)，只是入口 async 參數(shù)不同）不過(guò)我們需要知道異步釋放的好處（不阻塞主線程）和它的壞處（需要進(jìn)行一些線程同步相關(guān)的操作，內(nèi)存釋放不及時(shí)）。

至于說(shuō) string 為啥不異步釋放，主要是作者認(rèn)為它是一整塊內(nèi)存空間，計(jì)算閾值的時(shí)候 string 的結(jié)果固定是 1，那么就 <= 64，就是同步釋放。

在補(bǔ)充一點(diǎn)，前面舉例是說(shuō)的 list，底層是用的 quicklist，嚴(yán)格來(lái)說(shuō)統(tǒng)計(jì)的是 quicklistNode 的節(jié)點(diǎn)數(shù)量，就不是列表元素?cái)?shù)量。

像 zset 那些如果用的 ziplist/listpack 編碼的話，這種計(jì)算出來(lái)的閾值是 1，就也不是元素?cái)?shù)量。如果是跳表編碼的話就是統(tǒng)計(jì)的元素?cái)?shù)量。

然后至于選擇的話，大部分情況可以無(wú)腦用 UNLINK，不過(guò)需要知道壞處。

例如對(duì)于每一次的 async delete，主線程給子線程提交任務(wù)時(shí)需要加鎖解鎖，bio 子線程消費(fèi)任務(wù)的時(shí)候也要加鎖解鎖，要做一些線程同步，還有線程上下文切換，這些都是可能會(huì)有的潛在的問(wèn)題，如果小元素都異步釋放的話，的確代價(jià)可能會(huì)大，多線程做事情的確是會(huì)有這些麻煩。

可以多做壓測(cè)來(lái)驗(yàn)證環(huán)境里到底哪個(gè)好，不過(guò)大部分情況這些我們不用關(guān)系，只要寫(xiě)代碼的時(shí)候有意識(shí)的注意大 key 的釋放就好。

審核編輯：劉清