點擊上方?好好學(xué)java?，選擇?星標(biāo)?公眾號

重磅資訊、干貨，第一時間送達(dá)

今日推薦：騰訊推出高性能 RPC 開發(fā)框架

個人原創(chuàng)100W+訪問量博客：點擊前往，查看更多

本文來源：http://kaito-kidd.com/2020/07/03/redis-latency-analysis/

Redis作為內(nèi)存數(shù)據(jù)庫，擁有非常高的性能，單個實例的QPS能夠達(dá)到10W左右。但我們在使用Redis時，經(jīng)常時不時會出現(xiàn)訪問延遲很大的情況，如果你不知道Redis的內(nèi)部實現(xiàn)原理，在排查問題時就會一頭霧水。

很多時候，Redis出現(xiàn)訪問延遲變大，都與我們的使用不當(dāng)或運維不合理導(dǎo)致的。

這篇文章我們就來分析一下Redis在使用過程中，經(jīng)常會遇到的延遲問題以及如何定位和分析。

使用復(fù)雜度高的命令

如果在使用Redis時，發(fā)現(xiàn)訪問延遲突然增大，如何進行排查？

首先，第一步，建議你去查看一下Redis的慢日志。Redis提供了慢日志命令的統(tǒng)計功能，我們通過以下設(shè)置，就可以查看有哪些命令在執(zhí)行時延遲比較大。

首先設(shè)置Redis的慢日志閾值，只有超過閾值的命令才會被記錄，這里的單位是微妙，例如設(shè)置慢日志的閾值為5毫秒，同時設(shè)置只保留最近1000條慢日志記錄：

#?命令執(zhí)行超過5毫秒記錄慢日志 CONFIG?SET?slowlog-log-slower-than?5000 #?只保留最近1000條慢日志 CONFIG?SET?slowlog-max-len?1000

設(shè)置完成之后，所有執(zhí)行的命令如果延遲大于5毫秒，都會被Redis記錄下來，我們執(zhí)行SLOWLOG get 5查詢最近5條慢日志：

127.0.0.1:6379>?SLOWLOG?get?5 1)?1)?(integer)?32693???????#?慢日志ID2)?(integer)?1593763337??#?執(zhí)行時間3)?(integer)?5299????????#?執(zhí)行耗時(微妙)4)?1)?"LRANGE"???????????#?具體執(zhí)行的命令和參數(shù)2)?"user_list_2000"3)?"0"4)?"-1" 2)?1)?(integer)?326922)?(integer)?15937633373)?(integer)?50444)?1)?"GET"2)?"book_price_1000" ...

通過查看慢日志記錄，我們就可以知道在什么時間執(zhí)行哪些命令比較耗時，如果你的業(yè)務(wù)經(jīng)常使用O(n)以上復(fù)雜度的命令，例如sort、sunion、zunionstore，或者在執(zhí)行O(n)命令時操作的數(shù)據(jù)量比較大，這些情況下Redis處理數(shù)據(jù)時就會很耗時。

如果你的服務(wù)請求量并不大，但Redis實例的CPU使用率很高，很有可能是使用了復(fù)雜度高的命令導(dǎo)致的。

解決方案就是，不使用這些復(fù)雜度較高的命令，并且一次不要獲取太多的數(shù)據(jù)，每次盡量操作少量的數(shù)據(jù)，讓Redis可以及時處理返回。

存儲大key

如果查詢慢日志發(fā)現(xiàn)，并不是復(fù)雜度較高的命令導(dǎo)致的，例如都是SET、DELETE操作出現(xiàn)在慢日志記錄中，那么你就要懷疑是否存在Redis寫入了大key的情況。

Redis在寫入數(shù)據(jù)時，需要為新的數(shù)據(jù)分配內(nèi)存，當(dāng)從Redis中刪除數(shù)據(jù)時，它會釋放對應(yīng)的內(nèi)存空間。

如果一個key寫入的數(shù)據(jù)非常大，Redis在分配內(nèi)存時也會比較耗時。同樣的，當(dāng)刪除這個key的數(shù)據(jù)時，釋放內(nèi)存也會耗時比較久。

你需要檢查你的業(yè)務(wù)代碼，是否存在寫入大key的情況，需要評估寫入數(shù)據(jù)量的大小，業(yè)務(wù)層應(yīng)該避免一個key存入過大的數(shù)據(jù)量。

那么有沒有什么辦法可以掃描現(xiàn)在Redis中是否存在大key的數(shù)據(jù)嗎？

Redis也提供了掃描大key的方法：

redis-cli?-h?$host?-p?$port?--bigkeys?-i?0.01

使用上面的命令就可以掃描出整個實例key大小的分布情況，它是以類型維度來展示的。

需要注意的是當(dāng)我們在線上實例進行大key掃描時，Redis的QPS會突增，為了降低掃描過程中對Redis的影響，我們需要控制掃描的頻率，使用-i參數(shù)控制即可，它表示掃描過程中每次掃描的時間間隔，單位是秒。

使用這個命令的原理，其實就是Redis在內(nèi)部執(zhí)行scan命令，遍歷所有key，然后針對不同類型的key執(zhí)行strlen、llen、hlen、scard、zcard來獲取字符串的長度以及容器類型(list/dict/set/zset)的元素個數(shù)。

而對于容器類型的key，只能掃描出元素最多的key，但元素最多的key不一定占用內(nèi)存最多，這一點需要我們注意下。不過使用這個命令一般我們是可以對整個實例中key的分布情況有比較清晰的了解。

針對大key的問題，Redis官方在4.0版本推出了lazy-free的機制，用于異步釋放大key的內(nèi)存，降低對Redis性能的影響。即使這樣，我們也不建議使用大key，大key在集群的遷移過程中，也會影響到遷移的性能，這個后面在介紹集群相關(guān)的文章時，會再詳細(xì)介紹到。

集中過期

有時你會發(fā)現(xiàn)，平時在使用Redis時沒有延時比較大的情況，但在某個時間點突然出現(xiàn)一波延時，而且報慢的時間點很有規(guī)律，例如某個整點，或者間隔多久就會發(fā)生一次。

如果出現(xiàn)這種情況，就需要考慮是否存在大量key集中過期的情況。

如果有大量的key在某個固定時間點集中過期，在這個時間點訪問Redis時，就有可能導(dǎo)致延遲增加。

Redis的過期策略采用主動過期+懶惰過期兩種策略：

• 主動過期：Redis內(nèi)部維護一個定時任務(wù)，默認(rèn)每隔100毫秒會從過期字典中隨機取出20個key，刪除過期的key，如果過期key的比例超過了25%，則繼續(xù)獲取20個key，刪除過期的key，循環(huán)往復(fù)，直到過期key的比例下降到25%或者這次任務(wù)的執(zhí)行耗時超過了25毫秒，才會退出循環(huán)

• 懶惰過期：只有當(dāng)訪問某個key時，才判斷這個key是否已過期，如果已經(jīng)過期，則從實例中刪除

注意，Redis的主動過期的定時任務(wù)，也是在Redis主線程中執(zhí)行的，也就是說如果在執(zhí)行主動過期的過程中，出現(xiàn)了需要大量刪除過期key的情況，那么在業(yè)務(wù)訪問時，必須等這個過期任務(wù)執(zhí)行結(jié)束，才可以處理業(yè)務(wù)請求。此時就會出現(xiàn)，業(yè)務(wù)訪問延時增大的問題，最大延遲為25毫秒。

而且這個訪問延遲的情況，不會記錄在慢日志里。慢日志中只記錄真正執(zhí)行某個命令的耗時，Redis主動過期策略執(zhí)行在操作命令之前，如果操作命令耗時達(dá)不到慢日志閾值，它是不會計算在慢日志統(tǒng)計中的，但我們的業(yè)務(wù)卻感到了延遲增大。

此時你需要檢查你的業(yè)務(wù)，是否真的存在集中過期的代碼，一般集中過期使用的命令是expireat或pexpireat命令，在代碼中搜索這個關(guān)鍵字就可以了。

如果你的業(yè)務(wù)確實需要集中過期掉某些key，又不想導(dǎo)致Redis發(fā)生抖動，有什么優(yōu)化方案？

解決方案是，在集中過期時增加一個隨機時間，把這些需要過期的key的時間打散即可。

偽代碼可以這么寫：

#?在過期時間點之后的5分鐘內(nèi)隨機過期掉 redis.expireat(key,?expire_time?+?random(300))

這樣Redis在處理過期時，不會因為集中刪除key導(dǎo)致壓力過大，阻塞主線程。

另外，除了業(yè)務(wù)使用需要注意此問題之外，還可以通過運維手段來及時發(fā)現(xiàn)這種情況。

做法是我們需要把Redis的各項運行數(shù)據(jù)監(jiān)控起來，執(zhí)行info可以拿到所有的運行數(shù)據(jù)，在這里我們需要重點關(guān)注expired_keys這一項，它代表整個實例到目前為止，累計刪除過期key的數(shù)量。

我們需要對這個指標(biāo)監(jiān)控，當(dāng)在很短時間內(nèi)這個指標(biāo)出現(xiàn)突增時，需要及時報警出來，然后與業(yè)務(wù)報慢的時間點對比分析，確認(rèn)時間是否一致，如果一致，則可以認(rèn)為確實是因為這個原因?qū)е碌难舆t增大。

實例內(nèi)存達(dá)到上限

有時我們把Redis當(dāng)做純緩存使用，就會給實例設(shè)置一個內(nèi)存上限maxmemory，然后開啟LRU淘汰策略。

當(dāng)實例的內(nèi)存達(dá)到了maxmemory后，你會發(fā)現(xiàn)之后的每次寫入新的數(shù)據(jù)，有可能變慢了。

導(dǎo)致變慢的原因是，當(dāng)Redis內(nèi)存達(dá)到maxmemory后，每次寫入新的數(shù)據(jù)之前，必須先踢出一部分?jǐn)?shù)據(jù)，讓內(nèi)存維持在maxmemory之下。

這個踢出舊數(shù)據(jù)的邏輯也是需要消耗時間的，而具體耗時的長短，要取決于配置的淘汰策略：

• allkeys-lru：不管key是否設(shè)置了過期，淘汰最近最少訪問的key

• volatile-lru：只淘汰最近最少訪問并設(shè)置過期的key

• allkeys-random：不管key是否設(shè)置了過期，隨機淘汰

• volatile-random：只隨機淘汰有設(shè)置過期的key

• allkeys-ttl：不管key是否設(shè)置了過期，淘汰即將過期的key

• noeviction：不淘汰任何key，滿容后再寫入直接報錯

• allkeys-lfu：不管key是否設(shè)置了過期，淘汰訪問頻率最低的key（4.0+支持）

• volatile-lfu：只淘汰訪問頻率最低的過期key（4.0+支持）

具體使用哪種策略，需要根據(jù)業(yè)務(wù)場景來決定。

我們最常使用的一般是allkeys-lru或volatile-lru策略，它們的處理邏輯是，每次從實例中隨機取出一批key（可配置），然后淘汰一個最少訪問的key，之后把剩下的key暫存到一個池子中，繼續(xù)隨機取出一批key，并與之前池子中的key比較，再淘汰一個最少訪問的key。以此循環(huán)，直到內(nèi)存降到maxmemory之下。

如果使用的是allkeys-random或volatile-random策略，那么就會快很多，因為是隨機淘汰，那么就少了比較key訪問頻率時間的消耗了，隨機拿出一批key后直接淘汰即可，因此這個策略要比上面的LRU策略執(zhí)行快一些。

但以上這些邏輯都是在訪問Redis時，真正命令執(zhí)行之前執(zhí)行的，也就是它會影響我們訪問Redis時執(zhí)行的命令。

另外，如果此時Redis實例中有存儲大key，那么在淘汰大key釋放內(nèi)存時，這個耗時會更加久，延遲更大，這需要我們格外注意。

如果你的業(yè)務(wù)訪問量非常大，并且必須設(shè)置maxmemory限制實例的內(nèi)存上限，同時面臨淘汰key導(dǎo)致延遲增大的的情況，要想緩解這種情況，除了上面說的避免存儲大key、使用隨機淘汰策略之外，也可以考慮拆分實例的方法來緩解，拆分實例可以把一個實例淘汰key的壓力分?jǐn)偟蕉鄠€實例上，可以在一定程度降低延遲。

fork耗時嚴(yán)重

如果你的Redis開啟了自動生成RDB和AOF重寫功能，那么有可能在后臺生成RDB和AOF重寫時導(dǎo)致Redis的訪問延遲增大，而等這些任務(wù)執(zhí)行完畢后，延遲情況消失。

遇到這種情況，一般就是執(zhí)行生成RDB和AOF重寫任務(wù)導(dǎo)致的。

生成RDB和AOF都需要父進程fork出一個子進程進行數(shù)據(jù)的持久化，在fork執(zhí)行過程中，父進程需要拷貝內(nèi)存頁表給子進程，如果整個實例內(nèi)存占用很大，那么需要拷貝的內(nèi)存頁表會比較耗時，此過程會消耗大量的CPU資源，在完成fork之前，整個實例會被阻塞住，無法處理任何請求，如果此時CPU資源緊張，那么fork的時間會更長，甚至達(dá)到秒級。這會嚴(yán)重影響Redis的性能。

我們可以執(zhí)行info命令，查看最后一次fork執(zhí)行的耗時latest_fork_usec，單位微妙。這個時間就是整個實例阻塞無法處理請求的時間。

除了因為備份的原因生成RDB之外，在主從節(jié)點第一次建立數(shù)據(jù)同步時，主節(jié)點也會生成RDB文件給從節(jié)點進行一次全量同步，這時也會對Redis產(chǎn)生性能影響。

要想避免這種情況，我們需要規(guī)劃好數(shù)據(jù)備份的周期，建議在從節(jié)點上執(zhí)行備份，而且最好放在低峰期執(zhí)行。如果對于丟失數(shù)據(jù)不敏感的業(yè)務(wù)，那么不建議開啟AOF和AOF重寫功能。

另外，fork的耗時也與系統(tǒng)有關(guān)，如果把Redis部署在虛擬機上，那么這個時間也會增大。所以使用Redis時建議部署在物理機上，降低fork的影響。

綁定CPU

很多時候，我們在部署服務(wù)時，為了提高性能，降低程序在使用多個CPU時上下文切換的性能損耗，一般會采用進程綁定CPU的操作。

但在使用Redis時，我們不建議這么干，原因如下。

綁定CPU的Redis，在進行數(shù)據(jù)持久化時，fork出的子進程，子進程會繼承父進程的CPU使用偏好，而此時子進程會消耗大量的CPU資源進行數(shù)據(jù)持久化，子進程會與主進程發(fā)生CPU爭搶，這也會導(dǎo)致主進程的CPU資源不足訪問延遲增大。

所以在部署Redis進程時，如果需要開啟RDB和AOF重寫機制，一定不能進行CPU綁定操作！

開啟AOF

上面提到了，當(dāng)執(zhí)行AOF文件重寫時會因為fork執(zhí)行耗時導(dǎo)致Redis延遲增大，除了這個之外，如果開啟AOF機制，設(shè)置的策略不合理，也會導(dǎo)致性能問題。

開啟AOF后，Redis會把寫入的命令實時寫入到文件中，但寫入文件的過程是先寫入內(nèi)存，等內(nèi)存中的數(shù)據(jù)超過一定閾值或達(dá)到一定時間后，內(nèi)存中的內(nèi)容才會被真正寫入到磁盤中。

AOF為了保證文件寫入磁盤的安全性，提供了3種刷盤機制：

• appendfsync always：每次寫入都刷盤，對性能影響最大，占用磁盤IO比較高，數(shù)據(jù)安全性最高

• appendfsync everysec：1秒刷一次盤，對性能影響相對較小，節(jié)點宕機時最多丟失1秒的數(shù)據(jù)

• appendfsync no：按照操作系統(tǒng)的機制刷盤，對性能影響最小，數(shù)據(jù)安全性低，節(jié)點宕機丟失數(shù)據(jù)取決于操作系統(tǒng)刷盤機制

當(dāng)使用第一種機制appendfsync always時，Redis每處理一次寫命令，都會把這個命令寫入磁盤，而且這個操作是在主線程中執(zhí)行的。

內(nèi)存中的的數(shù)據(jù)寫入磁盤，這個會加重磁盤的IO負(fù)擔(dān)，操作磁盤成本要比操作內(nèi)存的代價大得多。如果寫入量很大，那么每次更新都會寫入磁盤，此時機器的磁盤IO就會非常高，拖慢Redis的性能，因此我們不建議使用這種機制。

與第一種機制對比，appendfsync everysec會每隔1秒刷盤，而appendfsync no取決于操作系統(tǒng)的刷盤時間，安全性不高。因此我們推薦使用appendfsync everysec這種方式，在最壞的情況下，只會丟失1秒的數(shù)據(jù)，但它能保持較好的訪問性能。

當(dāng)然，對于有些業(yè)務(wù)場景，對丟失數(shù)據(jù)并不敏感，也可以不開啟AOF。

使用Swap

如果你發(fā)現(xiàn)Redis突然變得非常慢，每次訪問的耗時都達(dá)到了幾百毫秒甚至秒級，那此時就檢查Redis是否使用到了Swap，這種情況下Redis基本上已經(jīng)無法提供高性能的服務(wù)。

我們知道，操作系統(tǒng)提供了Swap機制，目的是為了當(dāng)內(nèi)存不足時，可以把一部分內(nèi)存中的數(shù)據(jù)換到磁盤上，以達(dá)到對內(nèi)存使用的緩沖。

但當(dāng)內(nèi)存中的數(shù)據(jù)被換到磁盤上后，訪問這些數(shù)據(jù)就需要從磁盤中讀取，這個速度要比內(nèi)存慢太多！

尤其是針對Redis這種高性能的內(nèi)存數(shù)據(jù)庫來說，如果Redis中的內(nèi)存被換到磁盤上，對于Redis這種性能極其敏感的數(shù)據(jù)庫，這個操作時間是無法接受的。

我們需要檢查機器的內(nèi)存使用情況，確認(rèn)是否確實是因為內(nèi)存不足導(dǎo)致使用到了Swap。

如果確實使用到了Swap，要及時整理內(nèi)存空間，釋放出足夠的內(nèi)存供Redis使用，然后釋放Redis的Swap，讓Redis重新使用內(nèi)存。

釋放Redis的Swap過程通常要重啟實例，為了避免重啟實例對業(yè)務(wù)的影響，一般先進行主從切換，然后釋放舊主節(jié)點的Swap，重新啟動服務(wù)，待數(shù)據(jù)同步完成后，再切換回主節(jié)點即可。

可見，當(dāng)Redis使用到Swap后，此時的Redis的高性能基本被廢掉，所以我們需要提前預(yù)防這種情況。

我們需要對Redis機器的內(nèi)存和Swap使用情況進行監(jiān)控，在內(nèi)存不足和使用到Swap時及時報警出來，及時進行相應(yīng)的處理。

網(wǎng)卡負(fù)載過高

如果以上產(chǎn)生性能問題的場景，你都規(guī)避掉了，而且Redis也穩(wěn)定運行了很長時間，但在某個時間點之后開始，訪問Redis開始變慢了，而且一直持續(xù)到現(xiàn)在，這種情況是什么原因?qū)е碌?#xff1f;

之前我們就遇到這種問題，特點就是從某個時間點之后就開始變慢，并且一直持續(xù)。這時你需要檢查一下機器的網(wǎng)卡流量，是否存在網(wǎng)卡流量被跑滿的情況。

網(wǎng)卡負(fù)載過高，在網(wǎng)絡(luò)層和TCP層就會出現(xiàn)數(shù)據(jù)發(fā)送延遲、數(shù)據(jù)丟包等情況。Redis的高性能除了內(nèi)存之外，就在于網(wǎng)絡(luò)IO，請求量突增會導(dǎo)致網(wǎng)卡負(fù)載變高。

如果出現(xiàn)這種情況，你需要排查這個機器上的哪個Redis實例的流量過大占滿了網(wǎng)絡(luò)帶寬，然后確認(rèn)流量突增是否屬于業(yè)務(wù)正常情況，如果屬于那就需要及時擴容或遷移實例，避免這個機器的其他實例受到影響。

運維層面，我們需要對機器的各項指標(biāo)增加監(jiān)控，包括網(wǎng)絡(luò)流量，在達(dá)到閾值時提前報警，及時與業(yè)務(wù)確認(rèn)并擴容。

總結(jié)

以上我們總結(jié)了Redis中常見的可能導(dǎo)致延遲增大甚至阻塞的場景，這其中既涉及到了業(yè)務(wù)的使用問題，也涉及到Redis的運維問題。

可見，要想保證Redis高性能的運行，其中涉及到CPU、內(nèi)存、網(wǎng)絡(luò)，甚至磁盤的方方面面，其中還包括操作系統(tǒng)的相關(guān)特性的使用。

作為開發(fā)人員，我們需要了解Redis的運行機制，例如各個命令的執(zhí)行時間復(fù)雜度、數(shù)據(jù)過期策略、數(shù)據(jù)淘汰策略等，使用合理的命令，并結(jié)合業(yè)務(wù)場景進行優(yōu)化。

作為DBA運維人員，需要了解數(shù)據(jù)持久化、操作系統(tǒng)fork原理、Swap機制等，并對Redis的容量進行合理規(guī)劃，預(yù)留足夠的機器資源，對機器做好完善的監(jiān)控，才能保證Redis的穩(wěn)定運行。

最后，再附上我歷時三個月總結(jié)的?Java 面試 + Java 后端技術(shù)學(xué)習(xí)指南，筆者這幾年及春招的總結(jié)，github 1.4k star，拿去不謝！下載方式1.?首先掃描下方二維碼 2.?后臺回復(fù)「Java面試」即可獲取 《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的你的Redis为什么变慢了？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。