Redis作為內(nèi)存數(shù)據(jù)庫湾揽，擁有非常高的性能，單個(gè)實(shí)例的QPS能夠達(dá)到10W左右。但我們?cè)谑褂肦edis時(shí)库物，經(jīng)常時(shí)不時(shí)會(huì)出現(xiàn)訪問延遲很大的情況霸旗，如果你不知道Redis的內(nèi)部實(shí)現(xiàn)原理，在排查問題時(shí)就會(huì)一頭霧水戚揭。

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

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

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

如果在使用Redis時(shí)潜必，發(fā)現(xiàn)訪問延遲突然增大靴姿，如何進(jìn)行排查？

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

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

命令執(zhí)行超過5毫秒記錄慢日志

CONFIG SET slowlog-log-slower-than 5000

只保留最近1000條慢日志

CONFIG SET slowlog-max-len 1000

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

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

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

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

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

存儲(chǔ)大key

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

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

如果一個(gè)key寫入的數(shù)據(jù)非常大慢哈，Redis在分配內(nèi)存時(shí)也會(huì)比較耗時(shí)蔓钟。同樣的永票，當(dāng)刪除這個(gè)key的數(shù)據(jù)時(shí)，釋放內(nèi)存也會(huì)耗時(shí)比較久滥沫。

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

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

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

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

使用上面的命令就可以掃描出整個(gè)實(shí)例key大小的分布情況缀辩，它是以類型維度來展示的臭埋。

需要注意的是當(dāng)我們?cè)诰€上實(shí)例進(jìn)行大key掃描時(shí)，Redis的QPS會(huì)突增臀玄，為了降低掃描過程中對(duì)Redis的影響瓢阴，我們需要控制掃描的頻率，使用-i參數(shù)控制即可健无，它表示掃描過程中每次掃描的時(shí)間間隔荣恐，單位是秒。

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

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

針對(duì)大key的問題嘉汰，Redis官方在4.0版本推出了lazy-free的機(jī)制丹禀，用于異步釋放大key的內(nèi)存，降低對(duì)Redis性能的影響鞋怀。即使這樣双泪，我們也不建議使用大key，大key在集群的遷移過程中密似，也會(huì)影響到遷移的性能焙矛，這個(gè)后面在介紹集群相關(guān)的文章時(shí)，會(huì)再詳細(xì)介紹到残腌。

集中過期

有時(shí)你會(huì)發(fā)現(xiàn)村斟，平時(shí)在使用Redis時(shí)沒有延時(shí)比較大的情況，但在某個(gè)時(shí)間點(diǎn)突然出現(xiàn)一波延時(shí)抛猫，而且報(bào)慢的時(shí)間點(diǎn)很有規(guī)律蟆盹，例如某個(gè)整點(diǎn)，或者間隔多久就會(huì)發(fā)生一次闺金。

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

如果有大量的key在某個(gè)固定時(shí)間點(diǎn)集中過期败匹，在這個(gè)時(shí)間點(diǎn)訪問Redis時(shí)寨昙，就有可能導(dǎo)致延遲增加。

Redis的過期策略采用主動(dòng)過期+懶惰過期兩種策略：

主動(dòng)過期：Redis內(nèi)部維護(hù)一個(gè)定時(shí)任務(wù)掀亩，默認(rèn)每隔100毫秒會(huì)從過期字典中隨機(jī)取出20個(gè)key舔哪，刪除過期的key，如果過期key的比例超過了25%归榕，則繼續(xù)獲取20個(gè)key尸红，刪除過期的key，循環(huán)往復(fù)刹泄，直到過期key的比例下降到25%或者這次任務(wù)的執(zhí)行耗時(shí)超過了25毫秒外里，才會(huì)退出循環(huán)
懶惰過期：只有當(dāng)訪問某個(gè)key時(shí)，才判斷這個(gè)key是否已過期特石，如果已經(jīng)過期盅蝗，則從實(shí)例中刪除
注意，Redis的主動(dòng)過期的定時(shí)任務(wù)姆蘸，也是在Redis主線程中執(zhí)行的墩莫，也就是說如果在執(zhí)行主動(dòng)過期的過程中芙委，出現(xiàn)了需要大量刪除過期key的情況，那么在業(yè)務(wù)訪問時(shí)狂秦，必須等這個(gè)過期任務(wù)執(zhí)行結(jié)束灌侣，才可以處理業(yè)務(wù)請(qǐng)求。此時(shí)就會(huì)出現(xiàn)裂问，業(yè)務(wù)訪問延時(shí)增大的問題侧啼，最大延遲為25毫秒。

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

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

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

解決方案是铭污，在集中過期時(shí)增加一個(gè)隨機(jī)時(shí)間恋日，把這些需要過期的key的時(shí)間打散即可。

在過期時(shí)間點(diǎn)之后的5分鐘內(nèi)隨機(jī)過期掉

redis.expireat(key, expire_time + random(300))

這樣Redis在處理過期時(shí)嘹狞，不會(huì)因?yàn)榧袆h除key導(dǎo)致壓力過大岂膳，阻塞主線程。

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

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

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

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

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

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

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

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

allkeys-lru：不管key是否設(shè)置了過期炸卑，淘汰最近最少訪問的key
volatile-lru：只淘汰最近最少訪問并設(shè)置過期的key
allkeys-random：不管key是否設(shè)置了過期既鞠，隨機(jī)淘汰
volatile-random：只隨機(jī)淘汰有設(shè)置過期的key
allkeys-ttl：不管key是否設(shè)置了過期，淘汰即將過期的key
noeviction：不淘汰任何key盖文，滿容后再寫入直接報(bào)錯(cuò)
allkeys-lfu：不管key是否設(shè)置了過期嘱蛋，淘汰訪問頻率最低的key（4.0+支持）
volatile-lfu：只淘汰訪問頻率最低的過期key（4.0+支持）
具體使用哪種策略，需要根據(jù)業(yè)務(wù)場(chǎng)景來決定五续。

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

如果使用的是allkeys-random或volatile-random策略，那么就會(huì)快很多敞峭，因?yàn)槭请S機(jī)淘汰踊谋，那么就少了比較key訪問頻率時(shí)間的消耗了，隨機(jī)拿出一批key后直接淘汰即可旋讹，因此這個(gè)策略要比上面的LRU策略執(zhí)行快一些殖蚕。

但以上這些邏輯都是在訪問Redis時(shí)轿衔，真正命令執(zhí)行之前執(zhí)行的，也就是它會(huì)影響我們?cè)L問Redis時(shí)執(zhí)行的命令睦疫。

另外害驹，如果此時(shí)Redis實(shí)例中有存儲(chǔ)大key，那么在淘汰大key釋放內(nèi)存時(shí)蛤育，這個(gè)耗時(shí)會(huì)更加久宛官，延遲更大，這需要我們格外注意瓦糕。

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

fork耗時(shí)嚴(yán)重

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

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

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

我們可以執(zhí)行info命令佣蓉，查看最后一次fork執(zhí)行的耗時(shí)latest_fork_usec披摄，單位微妙亲雪。這個(gè)時(shí)間就是整個(gè)實(shí)例阻塞無法處理請(qǐng)求的時(shí)間。

除了因?yàn)閭浞莸脑蛏蒖DB之外疚膊，在主從節(jié)點(diǎn)第一次建立數(shù)據(jù)同步時(shí)义辕，主節(jié)點(diǎn)也會(huì)生成RDB文件給從節(jié)點(diǎn)進(jìn)行一次全量同步，這時(shí)也會(huì)對(duì)Redis產(chǎn)生性能影響寓盗。

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

另外续镇，fork的耗時(shí)也與系統(tǒng)有關(guān)，如果把Redis部署在虛擬機(jī)上销部，那么這個(gè)時(shí)間也會(huì)增大摸航。所以使用Redis時(shí)建議部署在物理機(jī)上，降低fork的影響舅桩。

綁定CPU

很多時(shí)候酱虎，我們?cè)诓渴鸱?wù)時(shí)，為了提高性能擂涛，降低程序在使用多個(gè)CPU時(shí)上下文切換的性能損耗读串，一般會(huì)采用進(jìn)程綁定CPU的操作。

但在使用Redis時(shí)撒妈，我們不建議這么干恢暖，原因如下。

綁定CPU的Redis狰右，在進(jìn)行數(shù)據(jù)持久化時(shí)杰捂，fork出的子進(jìn)程，子進(jìn)程會(huì)繼承父進(jìn)程的CPU使用偏好棋蚌，而此時(shí)子進(jìn)程會(huì)消耗大量的CPU資源進(jìn)行數(shù)據(jù)持久化嫁佳，子進(jìn)程會(huì)與主進(jìn)程發(fā)生CPU爭(zhēng)搶，這也會(huì)導(dǎo)致主進(jìn)程的CPU資源不足訪問延遲增大谷暮。

所以在部署Redis進(jìn)程時(shí)蒿往，如果需要開啟RDB和AOF重寫機(jī)制，一定不能進(jìn)行CPU綁定操作湿弦！

開啟AOF

上面提到了瓤漏，當(dāng)執(zhí)行AOF文件重寫時(shí)會(huì)因?yàn)閒ork執(zhí)行耗時(shí)導(dǎo)致Redis延遲增大，除了這個(gè)之外，如果開啟AOF機(jī)制蔬充，設(shè)置的策略不合理俯在，也會(huì)導(dǎo)致性能問題。

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

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

appendfsync always：每次寫入都刷盤皿哨，對(duì)性能影響最大浅侨，占用磁盤IO比較高，數(shù)據(jù)安全性最高
appendfsync everysec：1秒刷一次盤证膨，對(duì)性能影響相對(duì)較小如输，節(jié)點(diǎn)宕機(jī)時(shí)最多丟失1秒的數(shù)據(jù)
appendfsync no：按照操作系統(tǒng)的機(jī)制刷盤，對(duì)性能影響最小央勒，數(shù)據(jù)安全性低不见，節(jié)點(diǎn)宕機(jī)丟失數(shù)據(jù)取決于操作系統(tǒng)刷盤機(jī)制
當(dāng)使用第一種機(jī)制appendfsync always時(shí)，Redis每處理一次寫命令崔步，都會(huì)把這個(gè)命令寫入磁盤稳吮，而且這個(gè)操作是在主線程中執(zhí)行的。

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

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

當(dāng)然缓溅，對(duì)于有些業(yè)務(wù)場(chǎng)景进鸠，對(duì)丟失數(shù)據(jù)并不敏感，也可以不開啟AOF邢笙。

使用Swap

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

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

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

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

我們需要檢查機(jī)器的內(nèi)存使用情況，確認(rèn)是否確實(shí)是因?yàn)閮?nèi)存不足導(dǎo)致使用到了Swap议泵。

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

釋放Redis的Swap過程通常要重啟實(shí)例池充，為了避免重啟實(shí)例對(duì)業(yè)務(wù)的影響桩引，一般先進(jìn)行主從切換，然后釋放舊主節(jié)點(diǎn)的Swap收夸，重新啟動(dòng)服務(wù)坑匠，待數(shù)據(jù)同步完成后，再切換回主節(jié)點(diǎn)即可卧惜。

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

我們需要對(duì)Redis機(jī)器的內(nèi)存和Swap使用情況進(jìn)行監(jiān)控，在內(nèi)存不足和使用到Swap時(shí)及時(shí)報(bào)警出來茅姜，及時(shí)進(jìn)行相應(yīng)的處理闪朱。

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

如果以上產(chǎn)生性能問題的場(chǎng)景，你都規(guī)避掉了，而且Redis也穩(wěn)定運(yùn)行了很長時(shí)間奋姿，但在某個(gè)時(shí)間點(diǎn)之后開始锄开，訪問Redis開始變慢了，而且一直持續(xù)到現(xiàn)在称诗，這種情況是什么原因?qū)е碌模?/p>

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

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

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

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

總結(jié)

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

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

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

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