在 Redis 中，還有哪些其他命令可以代替 KEYS 命令，實現(xiàn)同樣的功能呢？這些命令的復(fù)雜度會導(dǎo)致 Redis 變慢嗎？

如果想要獲取整個實例的所有key，建議使用SCAN命令代替。客戶端通過執(zhí)行SCAN $cursor COUNT $count可以得到一批key以及下一個游標(biāo)$cursor，然后把這個$cursor當(dāng)作SCAN的參數(shù)，再次執(zhí)行，以此往復(fù)，直到返回的$cursor為0時，就把整個實例中的所有key遍歷出來了。

關(guān)于SCAN討論最多的問題就是，Redis在做Rehash時，會不會漏key或返回重復(fù)的key。

在使用SCAN命令時，不會漏key，但可能會得到重復(fù)的key，這主要和Redis的Rehash機(jī)制有關(guān)。Redis的所有key存在一個全局的哈希表中，如果存入的key慢慢變多，在達(dá)到一定閾值后，為了避免哈希沖突導(dǎo)致查詢效率降低，這個哈希表會進(jìn)行擴(kuò)容。與之對應(yīng)的，key數(shù)量逐漸變少時，這個哈希表會縮容以節(jié)省空間。

1、為什么不會漏key？Redis在SCAN遍歷全局哈希表時，采用*高位進(jìn)位法*的方式遍歷哈希桶（可網(wǎng)上查詢圖例，一看就明白），當(dāng)哈希表擴(kuò)容后，通過這種算法遍歷，舊哈希表中的數(shù)據(jù)映射到新哈希表，依舊會保留原來的先后順序，這樣就可以保證遍歷時不會遺漏也不會重復(fù)。

2、為什么SCAN會得到重復(fù)的key？這個情況主要發(fā)生在哈希表縮容。已經(jīng)遍歷過的哈希桶在縮容時，會映射到新哈希表沒有遍歷到的位置，所以繼續(xù)遍歷就會對同一個key返回多次。

SCAN是遍歷整個實例的所有key，另外Redis針對Hash/Set/Sorted Set也提供了HSCAN/SSCAN/ZSCAN命令，用于遍歷一個key中的所有元素，建議在獲取一個bigkey的所有數(shù)據(jù)時使用，避免發(fā)生阻塞風(fēng)險。

但是使用HSCAN/SSCAN/ZSCAN命令，返回的元素數(shù)量與執(zhí)行SCAN邏輯可能不同。執(zhí)行SCAN $cursor COUNT $count時一次最多返回count個數(shù)的key，數(shù)量不會超過count。

但Hash/Set/Sorted Set元素數(shù)量比較少時，底層會采用intset/ziplist方式存儲，如果以這種方式存儲，在執(zhí)行HSCAN/SSCAN/ZSCAN命令時，會無視count參數(shù)，直接把所有元素一次性返回，也就是說，得到的元素數(shù)量是會大于count參數(shù)的。當(dāng)?shù)讓愚D(zhuǎn)為哈希表或跳表存儲時，才會真正使用發(fā)count參數(shù)，最多返回count個元素。

總結(jié)

以上是生活随笔為你收集整理的redis中KEYS替代命令的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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