Redis 是一種內(nèi)存數(shù)據(jù)庫(kù)，將數(shù)據(jù)保存在內(nèi)存中，讀寫效率要比傳統(tǒng)的將數(shù)據(jù)保存在磁盤上的數(shù)據(jù)庫(kù)要快很多。但是 Redis 也會(huì)發(fā)生延遲時(shí)，這是就需要我們對(duì)其產(chǎn)生原因有深刻的了解，以便于快速排查問題，解決 Redis的延遲問題

[[282068]]

一條命令執(zhí)行過程

在本文場(chǎng)景下，延遲 (latency) 是指從客戶端發(fā)送命令到客戶端接收到命令返回值的時(shí)間間隔。所以我們先來看一下 Redis 一條命令執(zhí)行的步驟，其中每個(gè)步驟出問題都可能導(dǎo)致高延遲。

上圖是 Redis 客戶端發(fā)送一條命令的執(zhí)行過程示意圖，綠色的是執(zhí)行步驟，而藍(lán)色的則是可能出現(xiàn)的導(dǎo)致高延遲的原因。

網(wǎng)絡(luò)連接限制、網(wǎng)絡(luò)傳輸速率和CPU性能等是所有服務(wù)端都可能產(chǎn)生的性能問題。但是 Redis 有自己獨(dú)有的可能導(dǎo)致高延遲的問題：命令或者數(shù)據(jù)結(jié)構(gòu)誤用、持久化阻塞和內(nèi)存交換。

而且更為致命的是，Redis 采用單線程和事件驅(qū)動(dòng)的機(jī)制來處理網(wǎng)絡(luò)請(qǐng)求，分別有對(duì)應(yīng)的連接應(yīng)答處理器，命令請(qǐng)求處理器和命令回復(fù)處理器來處理客戶端的網(wǎng)絡(luò)請(qǐng)求事件，處理完一個(gè)事件就繼續(xù)處理隊(duì)列中的下一個(gè)。一條命令處理出現(xiàn)了高延遲會(huì)影響接下來處于排隊(duì)狀態(tài)的其他命令。

對(duì)于高延遲，Redis 原生提供慢查詢統(tǒng)計(jì)功能，執(zhí)行 slowlog get {n} 命令可以獲取最近的 n 條慢查詢命令，默認(rèn)對(duì)于執(zhí)行超過10毫秒(可配置)的命令都會(huì)記錄到一個(gè)定長(zhǎng)隊(duì)列中，線上實(shí)例建議設(shè)置為1毫秒便于及時(shí)發(fā)現(xiàn)毫秒級(jí)以上的命令。

# 超過 slowlog-log-slower-than 閾值的命令都會(huì)被記錄到慢查詢隊(duì)列中 
# 隊(duì)列最大長(zhǎng)度為 slowlog-max-len 
slowlog-log-slower-than 10000 
slowlog-max-len 128 

如果命令執(zhí)行時(shí)間在毫秒級(jí)，則實(shí)例實(shí)際OPS只有1000左右。慢查詢隊(duì)列長(zhǎng)度默認(rèn)128，可適當(dāng)調(diào)大。慢查詢本身只記錄了命令執(zhí)行時(shí)間，不包括數(shù)據(jù)網(wǎng)絡(luò)傳輸時(shí)間和命令排隊(duì)時(shí)間，因此客戶端發(fā)生阻塞異常 后，可能不是當(dāng)前命令緩慢，而是在等待其他命令執(zhí)行。需要重點(diǎn)比對(duì)異常和慢查詢發(fā)生的時(shí)間點(diǎn)，確認(rèn)是否有慢查詢?cè)斐傻拿钭枞抨?duì)。

slowlog的輸出格式如下所示。第一個(gè)字段表示該條記錄在所有慢日志中的序號(hào)，最新的記錄被展示在最前面;第二個(gè)字段是這條記錄被記錄時(shí)的系統(tǒng)時(shí)間，可以用 date 命令來將其轉(zhuǎn)換為友好的格式第三個(gè)字段表示這條命令的響應(yīng)時(shí)間，單位為 us (微秒);第四個(gè)字段為對(duì)應(yīng)的 Redis 操作。

> slowlog get 
1) 1) (integer) 26 
 2) (integer) 1450253133 
 3) (integer) 43097 
 4) 1) "flushdb" 

下面我們就來依次看一下不合理地使用命令或者數(shù)據(jù)結(jié)構(gòu)、持久化阻塞和內(nèi)存交換所導(dǎo)致的高延遲問題。

不合理的命令或者數(shù)據(jù)結(jié)構(gòu)

一般來說 Redis 執(zhí)行命令速度都非?？?，但是當(dāng)數(shù)據(jù)量達(dá)到一定級(jí)別時(shí)，某些命令的執(zhí)行就會(huì)花費(fèi)大量時(shí)間，比如對(duì)一個(gè)包含上萬個(gè)元素的 hash 結(jié)構(gòu)執(zhí)行 hgetall 操作，由于數(shù)據(jù)量比較大且命令算法復(fù)雜度是 O(n)，這條命令執(zhí)行速度必然很慢。

這個(gè)問題就是典型的不合理使用命令和數(shù)據(jù)結(jié)構(gòu)。對(duì)于高并發(fā)的場(chǎng)景我們應(yīng)該盡量避免在大對(duì)象上執(zhí)行算法復(fù)雜度超過 O(n) 的命令。對(duì)于鍵值較多的 hash 結(jié)構(gòu)可以使用 scan 系列命令來逐步遍歷，而不是直接使用 hgetall 來全部獲取。

Redis 本身提供發(fā)現(xiàn)大對(duì)象的工具，對(duì)應(yīng)命令：redis-cli-h {ip} -p {port} bigkeys。這條命令會(huì)使用 scan 從指定的 Redis DB 中持續(xù)采樣，實(shí)時(shí)輸出當(dāng)時(shí)得到的 value 占用空間最大的 key 值，并在最后給出各種數(shù)據(jù)結(jié)構(gòu)的 biggest key 的總結(jié)報(bào)告。

持久化阻塞

對(duì)于開啟了持久化功能的Redis節(jié)點(diǎn)，需要排查是否是持久化導(dǎo)致的阻 塞。持久化引起主線程阻塞的操作主要有：fork 阻塞、AOF刷盤阻塞。

fork 操作發(fā)生在 RDB 和 AOF 重寫時(shí)，Redis 主線程調(diào)用 fork 操作產(chǎn)生共享內(nèi)存的子進(jìn)程，由子進(jìn)程完成對(duì)應(yīng)的持久化工作。如果 fork 操作本身耗時(shí)過長(zhǎng)，必然會(huì)導(dǎo)致主線程的阻塞。

Redis 執(zhí)行 fork 操作產(chǎn)生的子進(jìn)程內(nèi)存占用量表現(xiàn)為與父進(jìn)程相同，理論上需要一倍的物理內(nèi)存來完成相應(yīng)的操作。但是 Linux 具有寫時(shí)復(fù)制技術(shù) (copy-on-write)，父子進(jìn)程會(huì)共享相同的物理內(nèi)存頁(yè)，當(dāng)父進(jìn)程處理寫請(qǐng)求時(shí)會(huì)對(duì)需要修改的頁(yè)復(fù)制出一份副本完成寫操作，而子進(jìn)程依然讀取 fork 時(shí)整個(gè)父進(jìn)程的內(nèi)存快照。所以，一般來說，fork 不會(huì)消耗過多時(shí)間。

可以執(zhí)行 info stats命令獲取到 latestforkusec 指標(biāo)，表示 Redis 最近一次 fork 操作耗時(shí)，如果耗時(shí)很大，比如超過1秒，則需要做出優(yōu)化調(diào)整。

> redis-cli -c -p 7000 info | grep -w latest_fork_usec 
latest_fork_usec:315 

當(dāng)我們開啟AOF持久化功能時(shí)，文件刷盤的方式一般采用每秒一次，后 臺(tái)線程每秒對(duì)AOF文件做 fsync 操作。當(dāng)硬盤壓力過大時(shí)，fsync 操作需要等待，直到寫入完成。如果主線程發(fā)現(xiàn)距離上一次的 fsync 成功超過2秒，為了數(shù)據(jù)安全性它會(huì)阻塞直到后臺(tái)線程執(zhí)行 fsync 操作完成。這種阻塞行為主要是硬盤壓力引起，可以查看 Redis日志識(shí)別出這種情況，當(dāng)發(fā)生這種阻塞行為時(shí)，會(huì)打印如下日志：

Asynchronous AOF fsync is taking too long (disk is busy). \ 
Writing the AOF buffer without waiting for fsync to complete, \ 
this may slow down Redis. 

也可以查看 info persistence 統(tǒng)計(jì)中的 aofdelayedfsync 指標(biāo)，每次發(fā)生 fdatasync 阻塞主線程時(shí)會(huì)累加。

>info persistence 
loading:0 
aof_pending_bio_fsync:0 
aof_delayed_fsync:0 

內(nèi)存交換

內(nèi)存交換(swap)對(duì)于 Redis 來說是非常致命的，Redis 保證高性能的一個(gè)重要前提是所有的數(shù)據(jù)在內(nèi)存中。如果操作系統(tǒng)把 Redis 使用的部分內(nèi)存換出到硬盤，由于內(nèi)存與硬盤讀寫速度差幾個(gè)數(shù)量級(jí)，會(huì)導(dǎo)致發(fā)生交換后的 Redis 性能急劇下降。識(shí)別 Redis 內(nèi)存交換的檢查方法如下：

>redis-cli -p 6383 info server | grep process_id # 查詢 redis 進(jìn)程號(hào) 
>cat /proc/4476/smaps | grep Swap # 查詢內(nèi)存交換大小 
Swap: 0 kB 
Swap: 4 kB 
Swap: 0 kB 
Swap: 0 kB 

如果交換量都是0KB或者個(gè)別的是4KB，則是正常現(xiàn)象，說明Redis進(jìn)程內(nèi)存沒有被交換。

有很多方法可以避免內(nèi)存交換的發(fā)生。比如說：

• 保證機(jī)器充足的可用內(nèi)存
• 確保所有Redis實(shí)例設(shè)置最大可用內(nèi)存(maxmemory)，防止極端情況下 Redis 內(nèi)存不可控的增長(zhǎng)。
• 降低系統(tǒng)使用swap優(yōu)先級(jí)，如 echo10>/proc/sys/vm/swappiness。