redis中的keys命令可以列出滿足特定正規表示式所有的key.命令的格式為keys pattern
但是它存在倆顯著的缺點
為解決此問題，2.8版本便加入年scan指令。
它有如下特點：
基本用法
scan cursor [match pattern] [count count]
cursor為設定的游標值。
先為redis增添一些鍵值對
public class insertdata }}
}
游標為何物？
在redis中所有的key都類似於hashmap一樣被存於乙個陣列（桶表）當中，而那個游標位置就是陣列的索引。
某個游標值的得到元素的或多或少與該桶中掛載的元素有關。limit表示遍歷的桶的數量，將這些桶進行模式匹配後一次性返回。
scan遍歷順序
它採用高位進製加法來遍歷。使用此方法是考慮到字典的擴容與縮容時避免桶重複和遺漏。而且高位擴容過來的順序是相鄰的。
0000 -+1-> 1000 -+1-> 0100 -+1->1100.....與hashmap類似，有乙個將桶中元素高1位hash值是否為1，如果是移至高位，否保持不變。
比如乙個元素的hash碼為1001。在桶為8時，在1號位置，在擴容後（桶為16），在9號位置。
擴容、縮容後的遍歷順序
由於高位進製加法，rehash後的桶的位置是相鄰的。
所以擴容後僅需找到需要遍歷的原位置之後的即可。
縮容與擴容類似，不過由於將兩個桶存到一起了，可能會重複遍歷之前已經遍歷過的內容，這大概就是要手動去重的原因吧。
漸近式rehash
就是會保留新舊兩種桶表，舊找不到就去新的找。就跟chm中加個**結點似的感覺(底層實現是怎樣的我不知道)。
scan還支援一些其他的指令，zscan、hscan等，原理類似
大key掃瞄
如果某個key過大，會造成集群環境下資料遷移時的卡頓。且擴容時會一次性申請更大的一塊記憶體，也會造成卡頓。且被清除時，一次性**，也會造成卡頓。
所以業務中盡量避免大key。
這種情況下也可以使用scan命令定位大key
在每隔100條指令休眠time秒。
redis-cli -h ip -p port --bigkeys -i time秒redis深度歷險06 key和scan
keys 獲得所有的key keys f 獲得f開頭的key keys f f 獲得f開頭，f結尾的key此方法的缺點 沒有分頁 複雜度o n 造成卡頓 複雜度o n 但是通過游標分布，不會阻塞。提供limit引數 提供模式匹配的方式 伺服器不需要儲存游標狀態，游標的唯一狀態就是scan返回給客戶端...
Redis深度歷險 核心原理與應用實踐
高可用架構 的各位老鐵們，你們好！你是否還記得上個月發布的文章中，有兩篇深入講解redis的文章，分別是 挑戰kafka redis5.0重量級特性stream嘗鮮 和 10個常見的redis面試 刁難 問題 廣大粉絲讀者們對這兩篇文章整體評價頗高。而我就是這兩篇文章的原創作者 老錢 錢文品 我是來...
Redis深度歷險 核心原理與應用實踐
高可用架構 的各位老鐵們，你們好！你是否還記得上個月發布的文章中，有兩篇深入講解redis的文章，分別是和，廣大粉絲讀者們對這兩篇文章整體評價頗高。而我就是這兩篇文章的原創作者 老錢 錢文品 我是來自掌閱的服務端技術專家。上週我用了蹩腳的英語向redis作者antirez就 跳躍列表 的演算法問題向...