Redis慢查詢的具體使用
什么是Redis慢查詢？
redis的"慢查詢"與redis定義慢查詢的時(shí)間閾值有關(guān)，Redis提供了slowlog-log-slower-than和slowlog-max-len兩個(gè)配置，slowlog-log-slower-than指當(dāng)redis命令的執(zhí)行時(shí)間超過該值時(shí)，redis會(huì)將其記錄在redis的慢查詢?nèi)罩局?，slowlog-max-len表示記錄的條數(shù)（超過時(shí)會(huì)只存儲(chǔ)最新的slowlog-max-len條），slowlog-log-slower-than的默認(rèn)值為10000us，也就是一般來說，redis命令執(zhí)行時(shí)間超過10ms時(shí)，我們認(rèn)為產(chǎn)生了慢查詢,redis慢查詢?nèi)罩居涗浀氖菆?zhí)行時(shí)間，沒有慢查詢，并不表示客戶端沒有超時(shí)問題，有可能網(wǎng)絡(luò)傳輸有延遲，也有可能排隊(duì)的命令比較多，導(dǎo)致redis查詢也很慢。
產(chǎn)生慢查詢有哪些原因？
在業(yè)務(wù)使用過程中，我們發(fā)現(xiàn)redis使用上出現(xiàn)慢查詢的原因有主要以下幾種：
- 使用復(fù)雜度過高的命令
- 大key問題
- 集中過期
如何解決慢查詢問題？
針對(duì)上述的原因，下面逐個(gè)給出導(dǎo)致慢查詢的原因細(xì)節(jié)，并提出對(duì)應(yīng)解決redis慢查詢的有效方法。
使用復(fù)雜度過高的命令
負(fù)責(zé)的命令一般指O(N)以上的命令，比如sort、sunion、zunionstore聚合類的命令，或是O(N)類的命令，但是N的值由于業(yè)務(wù)原因特別大。
對(duì)于O(N)以上的命令，redis在操作內(nèi)存數(shù)據(jù)時(shí)，耗時(shí)過高，會(huì)耗費(fèi)更多的cpu資源，導(dǎo)致查詢變慢。對(duì)于O(N)類的命令，由于N的值特別大Redis 一次需要返回給客戶端的數(shù)據(jù)過多，更多時(shí)間花費(fèi)在數(shù)據(jù)協(xié)議的組裝和網(wǎng)絡(luò)傳輸過程中。
除此之外，我們都知道，Redis 是單線程處理客戶端請(qǐng)求的，如果你經(jīng)常使用以上命令，那么當(dāng) Redis 處理客戶端請(qǐng)求時(shí)，一旦前面某個(gè)命令發(fā)生耗時(shí)，就會(huì)導(dǎo)致后面的請(qǐng)求發(fā)生排隊(duì)，對(duì)于客戶端來說，響應(yīng)延遲也會(huì)長(zhǎng)。
針對(duì)此類原因，我們一般有以下兩個(gè)原則：
- 盡量不使用O(N)以上復(fù)雜度的命令，某些數(shù)據(jù)排序或聚合操作，可以放在客戶端處理。
- 執(zhí)行O(N)命令時(shí)，保證 N 盡量的?。ㄍ扑] N <= 300 經(jīng)驗(yàn)值），每次獲取盡量少的數(shù)據(jù)，讓 Redis 可以及時(shí)處理返回。
大key問題
所謂大key問題其實(shí)并不是值key過大，實(shí)則值key對(duì)應(yīng)的value的值過大，此類問題在SET / DEL這類命令中也常出現(xiàn)慢查詢。
首先我們要了解下redis寫入與刪除數(shù)據(jù)做了什么：
- 寫入數(shù)據(jù):為該數(shù)據(jù)分配內(nèi)存。
- 刪除數(shù)據(jù)：釋放該數(shù)據(jù)對(duì)應(yīng)的內(nèi)存空間。
很明顯，當(dāng)數(shù)據(jù)值比較大時(shí)，redis分配數(shù)據(jù)內(nèi)存或釋放空間內(nèi)存都會(huì)比較耗時(shí)，針對(duì)大key問題，有以下建議：
- 盡量避免寫入大key(不要寫入無關(guān)的數(shù)據(jù)，數(shù)據(jù)實(shí)在過大可以進(jìn)行拆分，通過多key存儲(chǔ))
- 如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把釋放 key 內(nèi)存的操作，放到后臺(tái)線程中去執(zhí)行，從而降低對(duì) Redis 的影響
- 如果你使用的 Redis 是 6.0 以上版本，可以開啟 lazy-free 機(jī)制（lazyfree-lazy-user-del = yes），在執(zhí)行 DEL 命令時(shí)，釋放內(nèi)存也會(huì)放到后臺(tái)線程中執(zhí)行。
順邊提下檢測(cè)大key的一個(gè)命令:
redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01
輸出結(jié)果會(huì)展示每種數(shù)據(jù)類型所占用的最大內(nèi)存 / 擁有最多元素的 key 是哪一個(gè)，以及每種數(shù)據(jù)類型在整個(gè)實(shí)例中的占比和平均大小 / 元素?cái)?shù)量。
其實(shí)，使用這個(gè)命令的原理，就是 Redis 在內(nèi)部執(zhí)行了 SCAN 命令，遍歷整個(gè)實(shí)例中所有的 key，然后針對(duì) key 的類型，分別執(zhí)行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令，來獲取 String 類型的長(zhǎng)度、容器類型（List、Hash、Set、ZSet）的元素個(gè)數(shù)。
這里我需要提醒你的是，當(dāng)執(zhí)行這個(gè)命令時(shí)，要注意 2 個(gè)問題：
- 對(duì)線上實(shí)例進(jìn)行 bigkey 掃描時(shí)，Redis 的 OPS 會(huì)突增，為了降低掃描過程中對(duì) Redis 的影響，最好控制一下掃描的頻率，指定 -i 參數(shù)即可，它表示掃描過程中每次掃描后休息的時(shí)間間隔，單位是秒
- 掃描結(jié)果中，對(duì)于容器類型（List、Hash、Set、ZSet）的 key，只能掃描出元素最多的 key。但一個(gè) key 的元素多，不一定表示占用內(nèi)存也多，你還需要根據(jù)業(yè)務(wù)情況，進(jìn)一步評(píng)估內(nèi)存占用情況
集中過期
集中過期產(chǎn)生的慢查詢很容易被忽略，可能我們?cè)跇I(yè)務(wù)上線時(shí)，并沒有發(fā)生慢查詢，而是業(yè)務(wù)運(yùn)行時(shí)在某個(gè)時(shí)間點(diǎn)總是突然發(fā)生慢查詢。為什么集中過期會(huì)導(dǎo)致慢查詢呢？我們首先了解下redis的兩種過期策略：
- 被動(dòng)過期：只有當(dāng)訪問某個(gè)key時(shí)，才會(huì)檢測(cè)該key是否已經(jīng)過期，如果已經(jīng)過期則從實(shí)例刪除該key。
- 主動(dòng)過期：redis內(nèi)部存在一個(gè)定時(shí)任務(wù)，默認(rèn)每間隔100毫秒就會(huì)從全局的過期哈希表里面隨機(jī)取出20個(gè)key，然后刪除其中過期的 key，如果過期 key 的比例超過了 25%，則繼續(xù)重復(fù)此過程，直到過期 key 的比例下降到 25% 以下，或者這次任務(wù)的執(zhí)行耗時(shí)超過了 25 毫秒，才會(huì)退出循環(huán)。
值得注意的是，主動(dòng)過期key的定時(shí)任務(wù)是在redis主線程種執(zhí)行的，也就是說如果在執(zhí)行主動(dòng)過期的過程中，出現(xiàn)了集中過期，那就需要大量刪除過期 key ，那么此時(shí)應(yīng)用程序在訪問 Redis 時(shí)，必須要等待這個(gè)過期任務(wù)執(zhí)行結(jié)束，Redis 才可以服務(wù)這個(gè)客戶端請(qǐng)求，此時(shí)應(yīng)用訪問 Redis 就可能產(chǎn)生查詢。
如果此時(shí)需要過期刪除的是一個(gè) bigkey，那么這個(gè)耗時(shí)會(huì)更久。而且，這個(gè)操作延遲的命令并不會(huì)記錄在慢日志中。
因?yàn)槁罩局兄?strong>記錄一個(gè)命令真正操作內(nèi)存數(shù)據(jù)的耗時(shí)，而 Redis 主動(dòng)刪除過期 key 的邏輯，是在命令真正執(zhí)行之前執(zhí)行的。
對(duì)于集中過期問題，有以下建議
- 避免集中過期，比如將過期時(shí)間隨機(jī)化，添加一個(gè)隨機(jī)的值，分散集中過期的key的過期時(shí)間，降低 Redis 清理過期 key 的壓力
- 對(duì)于Redis 是 4.0 以上版本，可以開啟 lazy-free 機(jī)制，當(dāng)刪除過期 key 時(shí)，把釋放內(nèi)存的操作放到后臺(tái)線程中執(zhí)行，避免阻塞主線程
總結(jié)
到此這篇關(guān)于Redis慢查詢的具體使用的文章就介紹到這了,更多相關(guān)Redis慢查詢內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
在web服務(wù)器中，高可用是指服務(wù)器可以正常訪問的時(shí)間，衡量的標(biāo)準(zhǔn)是在多長(zhǎng)時(shí)間內(nèi)可以提供正常服務(wù)(99.9%、99.99%、99.999%等等)，Redis中，實(shí)現(xiàn)高可用的技術(shù)主要包括持久化、主從復(fù)制、哨兵和cluster集群，感興趣的同學(xué)可以閱讀本文2023-04-04
Redis大key指value過大、元素過多或結(jié)構(gòu)復(fù)雜,易引發(fā)阻塞、網(wǎng)絡(luò)延遲、內(nèi)存不均及持久化問題,需拆分?jǐn)?shù)據(jù)、優(yōu)化結(jié)構(gòu)、設(shè)置過期、漸進(jìn)刪除,并通過監(jiān)控與設(shè)計(jì)預(yù)防確保系統(tǒng)穩(wěn)定2025-07-07
redis啟動(dòng)停止,查看redis端口實(shí)現(xiàn)方式
文章主要講述了如何查看Redis進(jìn)程、停止Redis以及使用配置文件啟動(dòng)Redis集群和Sentinel哨兵的方法,并提到可以通過兩種方法后臺(tái)啟動(dòng)Redis服務(wù),作者表示這些是個(gè)人經(jīng)驗(yàn),希望能為大家提供參考2026-05-05
本文介紹了Redis 8.2.1版本如何通過腳本解密后注入或使用外部認(rèn)證模塊來實(shí)現(xiàn)密碼的安全存儲(chǔ)與使用,避免了配置文件中明文密碼的暴露風(fēng)險(xiǎn),下面詳細(xì)說明具體情況和解決方案,感興趣的朋友跟隨小編一起看看吧2026-03-03
Deepin UOS編譯安裝Redis的實(shí)現(xiàn)步驟
本文主要介紹了Deepin UOS編譯安裝Redis的實(shí)現(xiàn)步驟，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-01-01
Redis Cluster集群收縮主從節(jié)點(diǎn)詳細(xì)教程
集群收縮的源端就是要下線的主節(jié)點(diǎn)，目標(biāo)端就是在線的主節(jié)點(diǎn)，這篇文章主要介紹了Redis Cluster集群收縮主從節(jié)點(diǎn)詳細(xì)教程,需要的朋友可以參考下2021-11-11
本文主要介紹了Redis中的BigKey問題及其處理方法,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2025-02-02
Redis禁用命令、危險(xiǎn)命令及規(guī)避方法
這篇文章主要介紹了Redis禁用命令、危險(xiǎn)命令及規(guī)避方法,本文介紹了個(gè)非常致命的兩個(gè)命令以及用配置文件禁用這些命令的方法,需要的朋友可以參考下2015-06-06
本篇文章主要介紹了深入理解redis分布式鎖和消息隊(duì)列，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-07-07
Redis高效率原因及數(shù)據(jù)結(jié)構(gòu)分析
這篇文章主要為大家詳細(xì)的介紹了Redis高效的原因以及分析了Redis高效的數(shù)據(jù)結(jié)構(gòu)，有需要的朋友可以借鑒參考下，希望能夠有所幫助2021-09-09