共計 981 個字符，預計需要花費 3 分鐘才能閱讀完成。

本篇文章為大家展示了怎樣正確訪問 Redis 中的海量數據，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

一、前言

有時候我們需要知道線上的 Redis 的使用情況，尤其需要知道一些前綴的 key 值，讓我們怎么去查看呢？并且通常情況下 Redis 里的數據都是海量的，那么我們訪問 Redis 中的海量數據？如何避免事故產生！今天就給大家分享一個小知識點，希望大家輕噴。

二、事故產生

因為我們的用戶 token 緩存是采用了【user_token:userid】格式的 key，保存用戶的 token 的值。我們運維為了幫助開發小伙伴們查一下線上現在有多少登錄用戶。

直接用了 keys user_token* 方式進行查詢，事故就此發生了。導致 Redis 不可用，假死。

三、分析原因

我們線上的登錄用戶有幾百萬，數據量比較多；keys 算法是遍歷算法，復雜度是 O(n)，也就是數據越多，時間越高。

數據量達到幾百萬，keys 這個指令就會導致 Redis 服務卡頓，因為  Redis 是單線程程序，順序執行所有指令，其它指令必須等到當前的 keys 指令執行完了才可以繼續。

四、解決方案

那我們如何去遍歷大數據量呢？這個也是面試經常問的。我們可以采用 Redis 的另一個命令 scan。我們看一下 scan 的特點：

復雜度雖然也是 O(n)，但是它是通過游標分步進行的，不會阻塞線程

提供 count 參數，不是結果數量，是 Redis 單次遍歷字典槽位數量 (約等于)

同 keys 一樣，它也提供模式匹配功能;

服務器不需要為游標保存狀態，游標的唯一狀態就是  scan 返回給客戶端的游標整數;

返回的結果可能會有重復，需要客戶端去重復，這點非常重要;

單次返回的結果是空的并不意味著遍歷結束，而要看返回的游標值是否為零

4.1、scan 命令格式

4.2、命令解釋

scan 游標 MATCH 返回和給定模式相匹配的元素 count 每次迭代所返回的元素數量

SCAN 命令是增量的循環，每次調用只會返回一小部分的元素。所以不會讓 Redis 假死；

SCAN 命令返回的是一個游標，從 0 開始遍歷，到 0 結束遍歷；

4.3、舉例

從 0 開始遍歷，返回了游標 6，又返回了數據，繼續 scan 遍歷，就要從 6 開始

上述內容就是怎樣正確訪問 Redis 中的海量數據，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。