怎么確定Redis有性能問題及如何解決

本文小編為大家詳細(xì)介紹“怎么確定Redis有性能問題及如何解決”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“怎么確定Redis有性能問題及如何解決”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學(xué)習(xí)新知識(shí)吧。

Redis 通常是我們業(yè)務(wù)系統(tǒng)中一個(gè)重要的組件，比如：緩存、賬號(hào)登錄信息、排行榜等。

一旦 Redis 請(qǐng)求延遲增加，可能就會(huì)導(dǎo)致業(yè)務(wù)系統(tǒng)“雪崩”。

我在單身紅娘婚戀類型互聯(lián)網(wǎng)公司工作，在雙十一推出下單就送女朋友的活動(dòng)。

誰曾想，凌晨 12 點(diǎn)之后，用戶量暴增，出現(xiàn)了一個(gè)技術(shù)故障，用戶無法下單，當(dāng)時(shí)老大火冒三丈！

經(jīng)過查找發(fā)現(xiàn) Redis 報(bào) Could not get a resource from the pool。

獲取不到連接資源，并且集群中的單臺(tái) Redis 連接量很高。

大量的流量沒了 Redis 的緩存響應(yīng)，直接打到了 MySQL，最后數(shù)據(jù)庫也宕機(jī)了……

于是各種更改最大連接數(shù)、連接等待數(shù)，雖然報(bào)錯(cuò)信息頻率有所緩解，但還是持續(xù)報(bào)錯(cuò)。

后來經(jīng)過線下測試，發(fā)現(xiàn)存放 Redis 中的字符數(shù)據(jù)很大，平均 1s 返回?cái)?shù)據(jù)。

可以發(fā)現(xiàn)，一旦 Redis 延遲過高，會(huì)引發(fā)各種問題。

今天跟大家一起來分析下如何確定 Redis 有性能問題和解決方案。

Redis 性能出問題了么？

最大延遲是客戶端發(fā)出命令到客戶端收到命令的響應(yīng)的時(shí)間，正常情況下 Redis 處理的時(shí)間極短，在微秒級(jí)別。

當(dāng) Redis 出現(xiàn)性能波動(dòng)的時(shí)候，比如達(dá)到幾秒到十幾秒，這個(gè)很明顯我們可以認(rèn)定 Redis 性能變慢了。

有的硬件配置比較高，當(dāng)延遲 0.6ms，我們可能就認(rèn)定變慢了。硬件比較差的可能 3 ms 我們才認(rèn)為出現(xiàn)問題。

那我們?cè)撊绾味x Redis 真的變慢了呢？

所以，我們需要對(duì)當(dāng)前環(huán)境的 Redis 基線性能做測量，也就是在一個(gè)系統(tǒng)在低壓力、無干擾情況下的基本性能。

當(dāng)你發(fā)現(xiàn) Redis 運(yùn)行時(shí)時(shí)的延遲是基線性能的 2 倍以上，就可以判定 Redis 性能變慢了。

延遲基線測量

redis-cli 命令提供了–intrinsic-latency 選項(xiàng)，用來監(jiān)測和統(tǒng)計(jì)測試期間內(nèi)的最大延遲（以毫秒為單位），這個(gè)延遲可以作為 Redis 的基線性能。

redis-cli --latency -h `host` -p `port`

比如執(zhí)行如下指令：

redis-cli --intrinsic-latency 100
Max latency so far: 4 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 41 microseconds.
Max latency so far: 57 microseconds.
Max latency so far: 78 microseconds.
Max latency so far: 170 microseconds.
Max latency so far: 342 microseconds.
Max latency so far: 3079 microseconds.
45026981 total runs (avg latency: 2.2209 microseconds / 2220.89 nanoseconds per run).
Worst run took 1386x longer than the average latency.

注意：參數(shù)100是測試將執(zhí)行的秒數(shù)。我們運(yùn)行測試的時(shí)間越長，我們就越有可能發(fā)現(xiàn)延遲峰值。

通常運(yùn)行 100 秒通常是合適的，足以發(fā)現(xiàn)延遲問題了，當(dāng)然我們可以選擇不同時(shí)間運(yùn)行幾次，避免誤差。

運(yùn)行的最大延遲是 3079 微秒，所以基線性能是 3079 （3 毫秒）微秒。

需要注意的是，我們要在 Redis 的服務(wù)端運(yùn)行，而不是客戶端。這樣，可以避免網(wǎng)絡(luò)對(duì)基線性能的影響。

可以通過 -h host -p port 來連接服務(wù)端，如果想監(jiān)測網(wǎng)絡(luò)對(duì) Redis 的性能影響，可以使用 Iperf 測量客戶端到服務(wù)端的網(wǎng)絡(luò)延遲。

如果網(wǎng)絡(luò)延遲幾百毫秒，說明網(wǎng)絡(luò)可能有其他大流量的程序在運(yùn)行導(dǎo)致網(wǎng)絡(luò)擁塞，需要找運(yùn)維協(xié)調(diào)網(wǎng)絡(luò)的流量分配。

慢指令監(jiān)控

如何判斷是否是慢指令呢？

看操作復(fù)雜度是否是O(N)。官方文檔對(duì)每個(gè)命令的復(fù)雜度都有介紹，盡可能使用O(1) 和 O(log N)命令。

涉及到集合操作的復(fù)雜度一般為O(N)，比如集合全量查詢HGETALL、SMEMBERS，以及集合的聚合操作：SORT、LREM、 SUNION等。

有監(jiān)控?cái)?shù)據(jù)可以觀測呢？代碼不是我寫的，不知道有沒有人用了慢指令。

有兩種方式可以排查到：

• 使用 Redis 慢日志功能查出慢命令；

• latency-monitor（延遲監(jiān)控）工具。

此外，可以使用自己（top、htop、prstat 等）快速檢查 Redis 主進(jìn)程的 CPU 消耗。如果 CPU 使用率很高而流量不高，通常表明使用了慢速命令。

慢日志功能

Redis 中的 slowlog 命令可以讓我們快速定位到那些超出指定執(zhí)行時(shí)間的慢命令，默認(rèn)情況下命令若是執(zhí)行時(shí)間超過 10ms 就會(huì)被記錄到日志。

slowlog 只會(huì)記錄其命令執(zhí)行的時(shí)間，不包含 io 往返操作，也不記錄單由網(wǎng)絡(luò)延遲引起的響應(yīng)慢。

我們可以根據(jù)基線性能來自定義慢命令的標(biāo)準(zhǔn)（配置成基線性能最大延遲的 2 倍），調(diào)整觸發(fā)記錄慢命令的閾值。

可以在 redis-cli 中輸入以下命令配置記錄 6 毫秒以上的指令：

redis-cli CONFIG SET slowlog-log-slower-than 6000

也可以在 Redis.config 配置文件中設(shè)置，以微秒為單位。

想要查看所有執(zhí)行時(shí)間比較慢的命令，可以通過使用 Redis-cli 工具，輸入 slowlog get 命令查看，返回結(jié)果的第三個(gè)字段以微秒位單位顯示命令的執(zhí)行時(shí)間。

假如只需要查看最后 2 個(gè)慢命令，輸入 slowlog get 2 即可。

示例：獲取最近2個(gè)慢查詢命令

127.0.0.1:6381> SLOWLOG get 2
1) 1) (integer) 6
   2) (integer) 1458734263
   3) (integer) 74372
   4) 1) "hgetall"
      2) "max.dsp.blacklist"
2) 1) (integer) 5
   2) (integer) 1458734258
   3) (integer) 5411075
   4) 1) "keys"
      2) "max.dsp.blacklist"

以第一個(gè) HGET 命令為例分析，每個(gè) slowlog 實(shí)體共 4 個(gè)字段：

• 字段 1：1 個(gè)整數(shù)，表示這個(gè) slowlog 出現(xiàn)的序號(hào)，server 啟動(dòng)后遞增，當(dāng)前為 6。

• 字段 2：表示查詢執(zhí)行時(shí)的 Unix 時(shí)間戳。

• 字段 3：表示查詢執(zhí)行微秒數(shù),當(dāng)前是 74372 微秒,約 74ms。

• 字段 4: 表示查詢的命令和參數(shù),如果參數(shù)很多或很大,只會(huì)顯示部分參數(shù)個(gè)數(shù)。當(dāng)前命令是hgetall max.dsp.blacklist。

Latency Monitoring

Redis 在 2.8.13 版本引入了 Latency Monitoring 功能，用于以秒為粒度監(jiān)控各種事件的發(fā)生頻率。

啟用延遲監(jiān)視器的第一步是設(shè)置延遲閾值(單位毫秒)。只有超過該閾值的時(shí)間才會(huì)被記錄，比如我們根據(jù)基線性能（3ms）的 3 倍設(shè)置閾值為 9 ms。

可以用 redis-cli 設(shè)置也可以在 Redis.config 中設(shè)置；

CONFIG SET latency-monitor-threshold 9

工具記錄的相關(guān)事件的詳情可查看官方文檔：https://redis.io/topics/latency-monitor

如獲取最近的 latency

127.0.0.1:6379> debug sleep 2
OK
(2.00s)
127.0.0.1:6379> latency latest
1) 1) "command"
   2) (integer) 1645330616
   3) (integer) 2003
   4) (integer) 2003

事件的名稱；

事件發(fā)生的最新延遲的 Unix 時(shí)間戳；

毫秒為單位的時(shí)間延遲；

該事件的最大延遲。

如何解決 Redis 變慢？

Redis 的數(shù)據(jù)讀寫由單線程執(zhí)行，如果主線程執(zhí)行的操作時(shí)間太長，就會(huì)導(dǎo)致主線程阻塞。

一起分析下都有哪些操作會(huì)阻塞主線程，我們又該如何解決？

網(wǎng)絡(luò)通信導(dǎo)致的延遲

客戶端使用 TCP/IP 連接或 Unix 域連接連接到 Redis。1 Gbit/s 網(wǎng)絡(luò)的典型延遲約為 200 us。

redis 客戶端執(zhí)行一條命令分 4 個(gè)過程：

發(fā)送命令－〉 命令排隊(duì) －〉 命令執(zhí)行－〉 返回結(jié)果

這個(gè)過程稱為 Round trip time(簡稱 RTT, 往返時(shí)間)，mget mset 有效節(jié)約了 RTT，但大部分命令（如 hgetall，并沒有 mhgetall）不支持批量操作，需要消耗 N 次 RTT ，這個(gè)時(shí)候需要 pipeline 來解決這個(gè)問題。

Redis pipeline 將多個(gè)命令連接在一起來減少網(wǎng)絡(luò)響應(yīng)往返次數(shù)。

redis-pipeline

慢指令導(dǎo)致的延遲

根據(jù)上文的慢指令監(jiān)控查詢文檔，查詢到慢查詢指令?？梢酝ㄟ^以下兩種方式解決：

比如在 Cluster 集群中，將聚合運(yùn)算等 O(N) 操作運(yùn)行在 slave 上，或者在客戶端完成。

使用高效的命令代替。使用增量迭代的方式，避免一次查詢大量數(shù)據(jù)，具體請(qǐng)查看SCAN、SSCAN、HSCAN和ZSCAN命令。

除此之外，生產(chǎn)中禁用KEYS 命令，它只適用于調(diào)試。因?yàn)樗鼤?huì)遍歷所有的鍵值對(duì)，所以操作延時(shí)高。

Fork 生成 RDB 導(dǎo)致的延遲

生成 RDB 快照，Redis 必須 fork 后臺(tái)進(jìn)程。fork 操作（在主線程中運(yùn)行）本身會(huì)導(dǎo)致延遲。

Redis 使用操作系統(tǒng)的多進(jìn)程寫時(shí)復(fù)制技術(shù) COW(Copy On Write) 來實(shí)現(xiàn)快照持久化，減少內(nèi)存占用。

寫時(shí)復(fù)制技術(shù)保證快照期間數(shù)據(jù)可修改

但 fork 會(huì)涉及到復(fù)制大量鏈接對(duì)象，一個(gè) 24 GB 的大型 Redis 實(shí)例需要 24 GB / 4 kB * 8 = 48 MB 的頁表。

執(zhí)行 bgsave 時(shí)，這將涉及分配和復(fù)制 48 MB 內(nèi)存。

此外，從庫加載 RDB 期間無法提供讀寫服務(wù)，所以主庫的數(shù)據(jù)量大小控制在 2~4G 左右，讓從庫快速的加載完成。

內(nèi)存大頁（transparent huge pages）

常規(guī)的內(nèi)存頁是按照 4 KB 來分配，Linux 內(nèi)核從 2.6.38 開始支持內(nèi)存大頁機(jī)制，該機(jī)制支持 2MB 大小的內(nèi)存頁分配。

Redis 使用了 fork 生成 RDB 做持久化提供了數(shù)據(jù)可靠性保證。

當(dāng)生成 RDB 快照的過程中，Redis 采用**寫時(shí)復(fù)制**技術(shù)使得主線程依然可以接收客戶端的寫請(qǐng)求。

也就是當(dāng)數(shù)據(jù)被修改的時(shí)候，Redis 會(huì)復(fù)制一份這個(gè)數(shù)據(jù)，再進(jìn)行修改。

采用了內(nèi)存大頁，生成 RDB 期間，即使客戶端修改的數(shù)據(jù)只有 50B 的數(shù)據(jù)，Redis 需要復(fù)制 2MB 的大頁。當(dāng)寫的指令比較多的時(shí)候就會(huì)導(dǎo)致大量的拷貝，導(dǎo)致性能變慢。

使用以下指令禁用 Linux 內(nèi)存大頁即可：

echo never > /sys/kernel/mm/transparent_hugepage/enabled

swap：操作系統(tǒng)分頁

當(dāng)物理內(nèi)存（內(nèi)存條）不夠用的時(shí)候，將部分內(nèi)存上的數(shù)據(jù)交換到 swap 空間上，以便讓系統(tǒng)不會(huì)因內(nèi)存不夠用而導(dǎo)致 oom 或者更致命的情況出現(xiàn)。

當(dāng)某進(jìn)程向 OS 請(qǐng)求內(nèi)存發(fā)現(xiàn)不足時(shí)，OS 會(huì)把內(nèi)存中暫時(shí)不用的數(shù)據(jù)交換出去，放在 SWAP 分區(qū)中，這個(gè)過程稱為 SWAP OUT。

當(dāng)某進(jìn)程又需要這些數(shù)據(jù)且 OS 發(fā)現(xiàn)還有空閑物理內(nèi)存時(shí)，又會(huì)把 SWAP 分區(qū)中的數(shù)據(jù)交換回物理內(nèi)存中，這個(gè)過程稱為 SWAP IN。

內(nèi)存 swap 是操作系統(tǒng)里將內(nèi)存數(shù)據(jù)在內(nèi)存和磁盤間來回?fù)Q入和換出的機(jī)制，涉及到磁盤的讀寫。

觸發(fā) swap 的情況有哪些呢？

對(duì)于 Redis 而言，有兩種常見的情況：

Redis 使用了比可用內(nèi)存更多的內(nèi)存；

與 Redis 在同一機(jī)器運(yùn)行的其他進(jìn)程在執(zhí)行大量的文件讀寫 I/O 操作（包括生成大文件的 RDB 文件和 AOF 后臺(tái)線程），文件讀寫占用內(nèi)存，導(dǎo)致 Redis 獲得的內(nèi)存減少，觸發(fā)了 swap。

我要如何排查是否因?yàn)?nbsp;swap 導(dǎo)致的性能變慢呢？

Linux 提供了很好的工具來排查這個(gè)問題，所以當(dāng)懷疑由于交換導(dǎo)致的延遲時(shí)，只需按照以下步驟排查。

獲取 Redis 實(shí)例 pid

$ redis-cli info | grep process_id
process_id:13160

進(jìn)入此進(jìn)程的 /proc 文件系統(tǒng)目錄：

cd /proc/13160

在這里有一個(gè) smaps 的文件，該文件描述了 Redis 進(jìn)程的內(nèi)存布局，運(yùn)行以下指令，用 grep 查找所有文件中的 Swap 字段。

$ cat smaps | egrep '^(Swap|Size)'
Size:                316 kB
Swap:                  0 kB
Size:                  4 kB
Swap:                  0 kB
Size:                  8 kB
Swap:                  0 kB
Size:                 40 kB
Swap:                  0 kB
Size:                132 kB
Swap:                  0 kB
Size:             720896 kB
Swap:                 12 kB

每行 Size 表示 Redis 實(shí)例所用的一塊內(nèi)存大小，和 Size 下方的 Swap 對(duì)應(yīng)這塊 Size 大小的內(nèi)存區(qū)域有多少數(shù)據(jù)已經(jīng)被換出到磁盤上了。

如果 Size == Swap 則說明數(shù)據(jù)被完全換出了。

可以看到有一個(gè) 720896 kB 的內(nèi)存大小有 12 kb 被換出到了磁盤上（僅交換了 12 kB），這就沒什么問題。

Redis 本身會(huì)使用很多大小不一的內(nèi)存塊，所以，你可以看到有很多 Size 行，有的很小，就是 4KB，而有的很大，例如 720896KB。不同內(nèi)存塊被換出到磁盤上的大小也不一樣。

敲重點(diǎn)了

如果 Swap 一切都是 0 kb，或者零星的 4k ，那么一切正常。

當(dāng)出現(xiàn)百 MB，甚至 GB 級(jí)別的 swap 大小時(shí)，就表明，此時(shí)，Redis 實(shí)例的內(nèi)存壓力很大，很有可能會(huì)變慢。

解決方案

增加機(jī)器內(nèi)存；

將 Redis 放在單獨(dú)的機(jī)器上運(yùn)行，避免在同一機(jī)器上運(yùn)行需要大量內(nèi)存的進(jìn)程，從而滿足 Redis 的內(nèi)存需求；

增加 Cluster 集群的數(shù)量分擔(dān)數(shù)據(jù)量，減少每個(gè)實(shí)例所需的內(nèi)存。

AOF 和磁盤 I/O 導(dǎo)致的延遲

為了保證數(shù)據(jù)可靠性，Redis 使用 AOF 和 RDB 快照實(shí)現(xiàn)快速恢復(fù)和持久化。

可以使用 appendfsync 配置將 AOF 配置為以三種不同的方式在磁盤上執(zhí)行 write 或者 fsync （可以在運(yùn)行時(shí)使用 CONFIG SET命令修改此設(shè)置，比如：redis-cli CONFIG SET appendfsync no）。

• no：Redis 不執(zhí)行 fsync，唯一的延遲來自于 write 調(diào)用，write 只需要把日志記錄寫到內(nèi)核緩沖區(qū)就可以返回。

• everysec：Redis 每秒執(zhí)行一次 fsync。使用后臺(tái)子線程異步完成 fsync 操作。最多丟失 1s 的數(shù)據(jù)。

• always：每次寫入操作都會(huì)執(zhí)行 fsync，然后用 OK 代碼回復(fù)客戶端（實(shí)際上 Redis 會(huì)嘗試將同時(shí)執(zhí)行的許多命令聚集到單個(gè) fsync 中），沒有數(shù)據(jù)丟失。在這種模式下，性能通常非常低，強(qiáng)烈建議使用快速磁盤和可以在短時(shí)間內(nèi)執(zhí)行 fsync 的文件系統(tǒng)實(shí)現(xiàn)。

我們通常將 Redis 用于緩存，數(shù)據(jù)丟失完全惡意從數(shù)據(jù)獲取，并不需要很高的數(shù)據(jù)可靠性，建議設(shè)置成 no 或者 everysec。

除此之外，避免 AOF 文件過大， Redis 會(huì)進(jìn)行 AOF 重寫，生成縮小的 AOF 文件。

可以把配置項(xiàng) no-appendfsync-on-rewrite設(shè)置為 yes，表示在 AOF 重寫時(shí)，不進(jìn)行 fsync 操作。

也就是說，Redis 實(shí)例把寫命令寫到內(nèi)存后，不調(diào)用后臺(tái)線程進(jìn)行 fsync 操作，就直接返回了。

expires 淘汰過期數(shù)據(jù)

Redis 有兩種方式淘汰過期數(shù)據(jù)：

• 惰性刪除：當(dāng)接收請(qǐng)求的時(shí)候發(fā)現(xiàn) key 已經(jīng)過期，才執(zhí)行刪除；

• 定時(shí)刪除：每 100 毫秒刪除一些過期的 key。

定時(shí)刪除的算法如下：

隨機(jī)采樣 ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP個(gè)數(shù)的 key，刪除所有過期的 key；

如果發(fā)現(xiàn)還有超過 25% 的 key 已過期，則執(zhí)行步驟一。

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP默認(rèn)設(shè)置為 20，每秒執(zhí)行 10 次，刪除 200 個(gè) key 問題不大。

如果觸發(fā)了第二條，就會(huì)導(dǎo)致 Redis 一致在刪除過期數(shù)據(jù)去釋放內(nèi)存。而刪除是阻塞的。

觸發(fā)條件是什么呀？

也就是大量的 key 設(shè)置了相同的時(shí)間參數(shù)。同一秒內(nèi)，大量 key 過期，需要重復(fù)刪除多次才能降低到 25% 以下。

簡而言之：大量同時(shí)到期的 key 可能會(huì)導(dǎo)致性能波動(dòng)。

解決方案

如果一批 key 的確是同時(shí)過期，可以在 EXPIREAT 和 EXPIRE 的過期時(shí)間參數(shù)上，加上一個(gè)一定大小范圍內(nèi)的隨機(jī)數(shù)，這樣，既保證了 key 在一個(gè)鄰近時(shí)間范圍內(nèi)被刪除，又避免了同時(shí)過期造成的壓力。

bigkey

通常我們會(huì)將含有較大數(shù)據(jù)或含有大量成員、列表數(shù)的 Key 稱之為大 Key，下面我們將用幾個(gè)實(shí)際的例子對(duì)大 Key 的特征進(jìn)行描述：

• 一個(gè) STRING 類型的 Key，它的值為 5MB（數(shù)據(jù)過大）

• 一個(gè) LIST 類型的 Key，它的列表數(shù)量為 10000 個(gè)（列表數(shù)量過多）

• 一個(gè) ZSET 類型的 Key，它的成員數(shù)量為 10000 個(gè)（成員數(shù)量過多）

• 一個(gè) HASH 格式的 Key，它的成員數(shù)量雖然只有 1000 個(gè)但這些成員的 value 總大小為 10MB（成員體積過大）

bigkey 帶來問題如下：

• Redis 內(nèi)存不斷變大引發(fā) OOM，或者達(dá)到 maxmemory 設(shè) 置值引發(fā)寫阻塞或重要 Key 被逐出；

• Redis Cluster 中的某個(gè) node 內(nèi)存遠(yuǎn)超其余 node，但因 Redis Cluster 的數(shù)據(jù)遷移最小粒度為 Key 而無法將 node 上的內(nèi)存均衡化；

• bigkey 的讀請(qǐng)求占用過大帶寬，自身變慢的同時(shí)影響到該服務(wù)器上的其它服務(wù)；

• 刪除一個(gè) bigkey 造成主庫較長時(shí)間的阻塞并引發(fā)同步中斷或主從切換；

查找 bigkey

使用 redis-rdb-tools 工具以定制化方式找出大 Key。

解決方案

對(duì)大 key 拆分

如將一個(gè)含有數(shù)萬成員的 HASH Key 拆分為多個(gè) HASH Key，并確保每個(gè) Key 的成員數(shù)量在合理范圍，在 Redis Cluster 結(jié)構(gòu)中，大 Key 的拆分對(duì) node 間的內(nèi)存平衡能夠起到顯著作用。

異步清理大 key

Redis 自 4.0 起提供了 UNLINK 命令，該命令能夠以非阻塞的方式緩慢逐步的清理傳入的 Key，通過 UNLINK，你可以安全的刪除大 Key 甚至特大 Key。

讀到這里，這篇“怎么確定Redis有性能問題及如何解決”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注億速云行業(yè)資訊頻道。