[TOC]

redis 問題排查

Redis 服務本身問題CPU裂七、Memory罪既、磁盤 IO

1. 內(nèi)存問題

• used_memory_rss_human：表示目前的內(nèi)存實際占用——表示當前的內(nèi)存情況腰鬼。

• used_memory_peak_human：表示內(nèi)存峰值占用——表示曾經(jīng)的內(nèi)存情況（主要是用來抓不到現(xiàn)場的時候查問題用的）刻像。

• mem_fragmentation_ratio

  • 內(nèi)存碎片率( mem_fragmentation_ratio )指標給出了操作系統(tǒng)( used_memory_rss )使用的內(nèi)存與 Redis( used_memory )分配的內(nèi)存的比率 mem_fragmentation_ratio = used_memory_rss / used_memory 操作系統(tǒng)負責為每個進程分配物理內(nèi)存粟瞬，而操作系統(tǒng)中的虛擬內(nèi)存管理器保管著由內(nèi)存分配器分配的實際內(nèi)存映射 那么如果我們的 Redis 實例的內(nèi)存使用量為1 GB瞧哟，內(nèi)存分配器將首先嘗試找到一個連續(xù)的內(nèi)存段來存儲數(shù)據(jù)混巧；如果找不到連續(xù)的段，則分配器必須將進程的數(shù)據(jù)分成多個段勤揩，從而導致內(nèi)存開銷增加咧党，具體的相關解釋可參考這篇文章：Redis 內(nèi)存碎片的產(chǎn)生與清理 內(nèi)存碎片率大于1表示正在發(fā)生碎片，內(nèi)存碎片率超過1.5表示碎片過多陨亡，Redis 實例消耗了其實際申請的物理內(nèi)存的150%的內(nèi)存傍衡；另一方面深员，如果內(nèi)存碎片率低于1，則表示Redis需要的內(nèi)存多于系統(tǒng)上的可用內(nèi)存蛙埂，這會導致 swap 操作辨液。內(nèi)存交換到磁盤將導致延遲顯著增加 理想情況下，操作系統(tǒng)將在物理內(nèi)存中分配一個連續(xù)的段箱残，Redis 的內(nèi)存碎片率等于1或略大于1滔迈。

• maxmemory

  • 最大內(nèi)存限制 maxmemory，如果不設這個值被辑，可能導致內(nèi)存超過了系統(tǒng)可用內(nèi)存燎悍，然后就開始 swap，最終可能導致 OOM盼理。

• maxmemory-policy

  • 內(nèi)存超過限制后的處理策略谈山，默認是返回一個錯誤，如果設置為noeviction宏怔，則不會返回錯誤奏路，而是直接丟棄操作。

• evicted_keys

  • 表示由于 maxmemory 策略被驅逐出去的 key 的數(shù)量臊诊。

• 內(nèi)存碎片率

  • 內(nèi)存碎片率低的情況下可能會導致swqp內(nèi)存鸽粉。你看，這里其實是內(nèi)存和磁盤 IO 的聯(lián)動點抓艳。

hotkey 熱key

• redis 4.0以上的版本支持了每個節(jié)點上的基于LFU的熱點key發(fā)現(xiàn)機制触机，使用redis-cli –hotkeys即可，執(zhí)行redis-cli時加上–hotkeys選項玷或±苁祝可以定時在節(jié)點中使用該命令來發(fā)現(xiàn)對應熱點key。

[redis@flink1 bin]$ ./redis-cli -h 127.0.0.1 -p 27001  --hotkeys 

# Scanning the entire keyspace to find hot 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).

Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.

解決 redis hotkey 三板斧

• 如果是多實例的話偏友，就是經(jīng)典的讀寫分離蔬胯！

• 如果是單實例的話，就使用 pipeline 批量寫入位他。

• 如果pipeline無法滿足業(yè)務的話氛濒，就在業(yè)務服務只加一層緩存。

查看redis bigkeys 危害

• Redis 阻塞 ：因為 Redis 單線程特性，如果操作某個 bigkey 耗時比較久，則后面的請求會被阻塞魁索。
• 內(nèi)存空間不均勻 ：比如在 Redis cluster 或者 codis 中胆描，會造成節(jié)點的內(nèi)存使用不均勻。
• 過期時可能阻塞 ：如果 Bigkey 設置了過期時間醋粟，當過期后靡菇，這個 key 會被刪除重归，假如沒有使用 Redis 4.0 的過期異步刪除，就會存在阻塞 Redis 的可能性厦凤，并且慢查詢中查不到（因為這個刪除是內(nèi)部循環(huán)事件）鼻吮。
• 導致傾斜 ：某個實例上正好保存了 bigkey。bigkey 的 value 值很大（String 類型）较鼓，或者是 bigkey 保存了大量集合元素（集合類型）椎木，會導致這個實例的數(shù)據(jù)量增加，內(nèi)存資源消耗也相應增加博烂。實例的處理壓力就會增大香椎，速度變慢，甚至還可能會引起這個實例的內(nèi)存資源耗盡禽篱，從而崩潰畜伐。
• 關聯(lián)的知識點
  • 內(nèi)存大頁：內(nèi)存頁是用戶應用程序向操作系統(tǒng)申請內(nèi)存的單位，常規(guī)的內(nèi)存頁大小是 4KB躺率，而 Linux 內(nèi)核從 2.6.38 開始玛界，支持了內(nèi)存大頁機制，該機制允許應- 用程序以 2MB 大小為單位悼吱，向操作系統(tǒng)申請內(nèi)存慎框。
  • 由于系統(tǒng)采取的 COW（寫時復制）的方案、如果頻繁寫請求操作的是一個 bigkey后添，那主進程在拷貝這個 bigkey 內(nèi)存塊時鲤脏，涉及到的內(nèi)存大頁會更多，時間也會更久吕朵，從而延遲比較久猎醇。

查看bigkeys

[redis@flink1 bin]$ ./redis-cli -h 127.0.0.1 -p 27001   --bigkeys -i 0.01

# 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 set    found so far 'unactivezuoxiids:2211210001' with 2 members
[00.00%] Biggest zset   found so far 'recentContactsEntList:2108200002:CA43564FEE800002B8441BD0CDA016A1' with 1 members
[00.00%] Biggest zset   found so far 'agentList:499:12345' with 2 members
[00.00%] Biggest hash   found so far '4b7d2590-b17e-470f-8ff5-b690f6537e43' with 1 fields
[00.00%] Biggest hash   found so far 'agentInfo:1049:12345' with 7 fields
[00.00%] Biggest string found so far 'reconnoitre-2307140001-1059-1989-arrest_index' with 5 bytes
[02.29%] Biggest hash   found so far 'agentInfo:1001:2307140001' with 20 fields
[02.29%] Biggest set    found so far 'unactivezuoxiids:2108200002' with 13 members
[02.29%] Biggest hash   found so far 'agentInfo:10001:2108200002' with 21 fields
[04.58%] Biggest hash   found so far 'entInfo:2307140001' with 29 fields
[06.86%] Biggest list   found so far 'skillGroupList:10086' with 2 items
[13.96%] Biggest list   found so far 'skillGroupList:2307140001' with 3 items
[13.96%] Biggest zset   found so far 'agentList:473:2208220001' with 7 members
[16.25%] Biggest hash   found so far 'entInfo:2108200002' with 30 fields
[36.84%] Biggest zset   found so far 'agentList:515:2307140001' with 17 members
[41.42%] Biggest hash   found so far 'zsai:sn' with 76 fields
[55.15%] Biggest list   found so far 'skillGroupList:12345' with 7 items
[57.44%] Biggest list   found so far 'skillGroupList:2208220001' with 11 items
[78.49%] Biggest zset   found so far 'agentList:495:12345' with 45 members

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

Sampled 437 keys in the keyspace!
Total key length in bytes is 13455 (avg len 30.79)

Biggest   list found 'skillGroupList:2208220001' has 11 items
Biggest   hash found 'zsai:sn' has 76 fields
Biggest string found 'reconnoitre-2307140001-1059-1989-arrest_index' has 5 bytes
Biggest    set found 'unactivezuoxiids:2108200002' has 13 members
Biggest   zset found 'agentList:495:12345' has 45 members

20 lists with 43 items (04.58% of keys, avg size 2.15)
305 hashs with 2326 fields (69.79% of keys, avg size 7.63)
8 strings with 24 bytes (01.83% of keys, avg size 3.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
13 sets with 56 members (02.97% of keys, avg size 4.31)
91 zsets with 277 members (20.82% of keys, avg size 3.04)

Redis 數(shù)據(jù)存儲的問題key集中過期

• Redis 里面的 key 都會設置過期時間，有可能存在集中過期導致負載過高的問題努溃。

• 過期策略：這個策略是針對設置了過期時間的鍵（key）進行的硫嘶。當這些鍵到達過期時間，Redis會進行刪除處理梧税。過期策略主要有以下幾種方式：

  • 定時過期：每個設置了過期時間的key都會創(chuàng)建一個定時器沦疾，一旦到達過期時間就會立即清除。這種方式可以即時清除過期數(shù)據(jù)第队，對內(nèi)存管理非常友好哮塞，但可能會占用大量的CPU資源。
  • 定期刪除：Redis會將每個設置了過期時間的key放入到一個獨立的字典中凳谦，并定期（默認每秒十次忆畅，即每100ms一次）遍歷這個字典來刪除到期的key。這個過程并不是遍歷所有設置了過期時間的key尸执，而是采用了一種貪心策略家凯，例如從過期字典中隨機抽取一些key缓醋，檢查并刪除其中的已過期key。
  • 惰性刪除：在某些情況下绊诲，定期刪除可能會導致一些已經(jīng)過期的key并沒有被刪除送粱。惰性刪除就是在客戶端嘗試獲取一個已經(jīng)過期的key時，Redis會主動刪除這個key掂之，確保獲取操作一定不會得到過期的數(shù)據(jù)抗俄。

• 驅逐策略：這是當Redis的內(nèi)存使用達到上限時觸發(fā)的。Redis會使用一系列算法來決定要刪除哪些key世舰，以便為新數(shù)據(jù)騰出空間橄镜。驅逐策略有以下幾種方式：

  • noeviction：不進行驅逐，拒絕寫入新數(shù)據(jù)并返回錯誤信息冯乘。
  • allkeys-lru：從所有key中挑選最近最少使用的key進行刪除洽胶。
  • volatile-lru：從設置了過期時間的key中挑選最近最少使用的key進行刪除。
  • allkeys-random：從所有key中任意選擇key進行刪除裆馒。
  • volatile-random：從設置了過期時間的key中任意選擇key進行刪除姊氓。
  • volatile-ttl：從設置了過期時間的key中挑選剩余存活時間最短的key進行刪除。

Redis 數(shù)據(jù)存儲的問題——key 的總數(shù)

• info keyspace
  • 單實例建議控制在 1kw內(nèi)喷好；單實例鍵個數(shù)過大翔横，可能導致過期鍵的回收不及時。