在 Redis 中，還有哪些其他命令可以代替 KEYS 命令，實現同樣的功能呢？這些命令的復雜度會導致 Redis 變慢嗎？

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

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

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

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

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

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

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

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

總結

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

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