歡迎光臨
每天分享高質量文章

如何正確訪問Redis中的海量資料?服務才不會掛掉!

出處:www.toutiao.com/i6697540366528152077


一、前言

有時候我們需要知道線上的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開始

五、總結

這個是面試經常會問到的,也是我們小伙伴在工作的過程經常用的,一般資料量不大的時候,不會有什麼問題,但資料量多的時候,你的操作方式不對,你的績效就會被扣哦。

赞(0)

分享創造快樂