Redis進(jìn)階：一些簡(jiǎn)單運(yùn)維技巧

關(guān)于 Redis 的運(yùn)維，我的經(jīng)驗(yàn)僅限于安裝、備份，而且還是最簡(jiǎn)單的利用一些面板工具。之前很多篇文章中我都強(qiáng)調(diào)過，我沒有 Redis 的主從及分布式的真實(shí)項(xiàng)目經(jīng)歷。經(jīng)歷過的流量最大的項(xiàng)目也只是一臺(tái) Redis 實(shí)例就抗住了。畢竟 Redis 具有號(hào)稱單機(jī)單實(shí)例寫入 8萬/秒 ，讀取 11萬/秒 的能力，咱們一般的項(xiàng)目根本達(dá)不到啊。而且即使機(jī)器性能有差異，減一半，甚至減三分之一，3萬/秒 的讀取和寫入的系統(tǒng)咱也沒接觸過。（最大接觸到的是 3000條數(shù)據(jù)/秒 寫入 List 隊(duì)列）

因此，用不上也就接觸不到，簡(jiǎn)單配置的一臺(tái) Redis 的性能就比我所接觸過的最高流量上限還高了很多了。很多運(yùn)維及優(yōu)化相關(guān)的內(nèi)容沒法以真實(shí)的項(xiàng)目經(jīng)驗(yàn)來做為參考，這里也就只能是將一些看過的有印象的資料分享出來。

查看大 Key

Redis本身提供發(fā)現(xiàn)大對(duì)象的工具，對(duì)應(yīng)命令：redis-cli --bigkeys 。注意，是 redis-cli 的參數(shù)哦。

?  ~ redis-cli --bigkeys
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far '"a"' with 3 bytes
[00.00%] Biggest list   found so far '"b"' with 4 items

-------- summary -------

Sampled 2 keys in the keyspace!
Total key length in bytes is 2 (avg len 1.00)

Biggest   list found '"b"' has 4 items
Biggest string found '"a"' has 3 bytes

1 lists with 4 items (50.00% of keys, avg size 4.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
1 strings with 3 bytes (50.00% of keys, avg size 3.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

我這里沒什么數(shù)據(jù)，所以可能看不出啥效果，雖說看不出，但咱也得簡(jiǎn)單解釋一下。

• Biggest string found so far '"a"' with 3 bytes 包括下面那一條，就是每個(gè)類型中所找到的最大的 Key
• 底下還會(huì)統(tǒng)計(jì)每個(gè)類型中有幾個(gè)，復(fù)合類型中有幾個(gè) items 或者 fields ，同時(shí)在這些內(nèi)容中，一些比例信息，平均的大小等

雖說有這些內(nèi)容，如果需要按照某個(gè)閾值來查找指定的大鍵，還是沒法通過 --bigkey 來實(shí)現(xiàn)。這時(shí)，其實(shí)可以通過另外一個(gè)內(nèi)部命令來實(shí)現(xiàn)。

127.0.0.1:6379> hmset c a 111111 b 22
OK

127.0.0.1:6379> DEBUG OBJECT c
Value at:0x7fc197352960 refcount:1 encoding:ziplist serializedlength:26 lru:13093574 lru_seconds_idle:12

DEBUG OBJECT 用于返回調(diào)試對(duì)象的基本信息。在這些信息中，我們可以看到它現(xiàn)在是 ziplist 格式，數(shù)據(jù)長(zhǎng)度為 serializedlength ，簡(jiǎn)單地理解，它就可以看成是 strlen 查看 String 類型的結(jié)果。這樣，我們就可以根據(jù)不同的 Key 占據(jù)的字節(jié)長(zhǎng)度來確定哪些是大 Key 。怎么刪除大 Key ？不記得的小伙伴趕緊來復(fù)習(xí)一下哦。

再問一個(gè)：怎么遍歷所有的 Key ？忘了 SCAN 命令了？不記得的小伙伴也請(qǐng)趕緊來復(fù)習(xí)一下。

操作大 Key

操作大 Key 一般是讀寫兩個(gè)方面，讀的話好說，盡量用 scan 系列命令代替 KEYS *，還包括 hscan、sscan、zscan 。寫的話，分段寫，不要一次大批量（幾萬上百萬）的插入、更新，或者干脆別用大 Key 。刪除的話，unlink 還記得吧，另外 6 以上版本，開啟 lazy-free 也可以讓 del 去后臺(tái)運(yùn)行。查詢數(shù)量，llen、hlen、scard、zcard 的性能沒問題，鏈表有記錄數(shù)量字段，返回很快。

記住，范圍操作都很慘！全是我們之前學(xué)習(xí)過的內(nèi)容，這個(gè) bigkey 問題也是非常常見的面試題。

監(jiān)控系統(tǒng)信息

通過 redis-cli --stat 命令，可以實(shí)時(shí)地監(jiān)控當(dāng)前 Redis 的使用情況。同樣，它也是一個(gè) redis-cli 的參數(shù)工具。

?  ~ redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
3          1.11M    1       0       92459301 (+0)       932
3          1.11M    1       0       92459302 (+1)       932
3          1.11M    1       0       92459303 (+1)       932
3          1.11M    1       0       92459304 (+1)       932
………………
………………

運(yùn)行之后，會(huì)不停地輸出當(dāng)前 Redis 的信息，包括 Key 的數(shù)量，占用內(nèi)存的大小，連接的客戶端信息等等。

查看內(nèi)存交換情況

內(nèi)存交換就是我們 Linux 系統(tǒng)中的 SWAP 部分的內(nèi)容。當(dāng)物理內(nèi)存不夠的時(shí)候，會(huì)借用一些磁盤空間來當(dāng)做類似 Windows 的虛擬內(nèi)存空間。既然一提到磁盤了，那肯定就有一個(gè)問題，性能會(huì)劇烈下降。

那么我們要怎么知道，當(dāng)前 Redis 是否使用了 SWAP 了呢？

首先看下當(dāng)前 Redis 的進(jìn)程 ID 。

?  ~ redis-cli info server | grep process_id
process_id:820

然后，到操作系統(tǒng)的 /proc 目錄下查看內(nèi)存交換情況。

 cat /proc/4476/smaps | grep Swap
 Swap: 0 kB
 ………………

如果交換量都是 0kB 或者個(gè)別的是 4kB ，則是正常現(xiàn)象，說明Redis進(jìn)程內(nèi)存沒有被交換。好了，現(xiàn)在我們知道了會(huì)有這個(gè)交換內(nèi)存的情況，也知道了怎么查看有沒有發(fā)生內(nèi)存交換，那么預(yù)防內(nèi)存交換的方法有哪些呢？

• 保證機(jī)器充足的可用內(nèi)存。
• 確保所有 Redis 實(shí)例設(shè)置最大可用內(nèi)存（maxmemory），防止極端情況下 Redis 內(nèi)存不可控的增長(zhǎng)。
• 降低系統(tǒng)使用swap優(yōu)先級(jí)，如echo 10 > /proc/sys/vm/swappiness ，具體信息大家可以查閱 Linux 相關(guān)的資料。

連接數(shù)問題

在學(xué)習(xí)配置文件時(shí)，我們就看到過，Redis 的連接數(shù)可以通過 maxclients 這個(gè)參數(shù)進(jìn)行配置，默認(rèn)情況下它是 10000 。當(dāng)我們有超過 10000 個(gè)客戶端來連接時(shí)，Redis 就會(huì)拒絕連接。

在 info 命令下的 stats 子命令中，有一個(gè) rejected_connections 屬性，表示的就是被拒絕的連接的數(shù)量。

?  ~ redis-cli info stats | grep rejected
rejected_connections:0

可以通過查看這個(gè)屬性，獲得當(dāng)前我們系統(tǒng)的連接情況，看是不是要適當(dāng)調(diào)節(jié) maxclients 的大小。注意，如果是非本機(jī)連接，還要注意操作系統(tǒng)的 ulimit 情況。

內(nèi)存碎片

同樣在配置文件中，我們也學(xué)習(xí)過內(nèi)存碎片相關(guān)的配置信息。在系統(tǒng)的實(shí)際運(yùn)行中，其實(shí)也可以在 info memory 中查看到內(nèi)存碎片的信息。

127.0.0.1:6379> info memory
# Memory
used_memory:1163184
…………
used_memory_rss:1626112
…………
…………
mem_fragmentation_ratio:1.45
…………

需要重點(diǎn)關(guān)注的就是上面這三個(gè)屬性的值。

• used_memory 使用的內(nèi)存
• used_memory_rss 從系統(tǒng)角度,顯示Redis進(jìn)程占用的物理內(nèi)存總量，與top及ps命令看到的值是一致的
• mem_fragmentation_ratio 上面這兩位的比值

實(shí)際使用的內(nèi)存比系統(tǒng)顯示占用的內(nèi)存小，說明有一些內(nèi)存沒有被正式的數(shù)據(jù)使用，而是被內(nèi)存碎片占用了。如果兩者相差很大，說明碎片率很嚴(yán)重。不過 mem_fragmentation_ratio 如果小于 1 也不是什么好事，說明 Redis 使用了 SWAP 交換內(nèi)存到磁盤了。

注意到我這里的 mem_fragmentation_ratio 比值計(jì)算其實(shí)是不精準(zhǔn)的，1626112/1163184 約等于 1.40 ，這一塊并沒有找到合適的資料來解釋，有相關(guān)經(jīng)驗(yàn)的小伙伴可以留言告知一下哈，或許也可能是我本地沒什么數(shù)據(jù)，還有別的虛占內(nèi)存被計(jì)算了之類的。要么咱們就暫且認(rèn)為 mem_fragmentation_ratio 的公式并不是完全的 used_memory_rss/used_memory ，可能還有別的參數(shù)。

可以看出，這個(gè)值大于 1 ，小于 1 都不是什么好事，但也很難控制在完整的 1 上，因此，一般認(rèn)為在 1 到 1.5 之間是比較健康的，超過 1.5 了就表示有 50% 的內(nèi)存被碎片占用了。

內(nèi)存碎片的處理，一是可以在配置文件中打開 activedefrag 讓系統(tǒng)自動(dòng)進(jìn)行碎片整理，另外也可以通過命令 MEMORY PURGE 命令手動(dòng)清理，但這個(gè)命令會(huì)占用主進(jìn)程，如果本身 Redis 占用的內(nèi)存非常大的話，會(huì)造成進(jìn)程卡頓。

緩存命中率

這個(gè)問題印象很深刻啊，為啥？因?yàn)槊嬖嚨臅r(shí)候被問到過，當(dāng)時(shí)年輕的我當(dāng)然毫無意外的回答不出來。其實(shí)，也是通過 info 就可以查看到緩存的命中情況，然后根據(jù)一個(gè)公式就可以計(jì)算出緩存的命中率了。

127.0.0.1:6379> info stats
# Stats
……………………
keyspace_hits:3316018
keyspace_misses:6362034
……………………

是的，就是這兩個(gè)屬性值。從名稱就可以看出，一個(gè)是鍵空間命中數(shù)，一個(gè)是未命中數(shù)。

有了這兩個(gè)基礎(chǔ)值后，命中率就可以這么算：命中數(shù)/（命中數(shù)+未命中數(shù)）。

上面信息中我們的系統(tǒng)命中率就是 3316018/(3316018+6362034) = 0.34 ，好像有點(diǎn)低呀，可不是，咱這是本地測(cè)試機(jī)呀。如果確實(shí)是命中率過低，要檢查緩存擊穿的問題，這個(gè)很影響命中率。另外還要注意的就是緩存過期和失效的時(shí)機(jī)與架構(gòu)設(shè)計(jì)，都是影響命中率的關(guān)鍵。

總結(jié)

Redis 正式學(xué)習(xí)系列的內(nèi)容到此為止了。通過這 30 篇文章和視頻的學(xué)習(xí)，相信咱們對(duì)基礎(chǔ)的 Redis 使用應(yīng)該是沒有什么太大的問題了，至少大部分面試常見題也是能夠輕松應(yīng)對(duì)了。或者說，最差最差咱也不只是會(huì)用 GET、SET 的那一類碼農(nóng)了，多少還是知道 List 、Hash 、Set 、Sorted Set 這些數(shù)據(jù)類型以及它們的應(yīng)用場(chǎng)景了。

好了，后續(xù)如果還有 Redis 相關(guān)的內(nèi)容，應(yīng)該也是偏優(yōu)化和實(shí)戰(zhàn)方面的內(nèi)容，不會(huì)包含在這個(gè)系列中，會(huì)是單獨(dú)的文章或者是其它學(xué)習(xí)系列中牽涉到 Redis 部分的一些內(nèi)容。

感謝大家的支持，腳步不要停歇，咱們接下來就先進(jìn)入到 Nginx 的學(xué)習(xí)中吧。