為什么說阻塞是Redis的噩夢：

　　Redis是典型的單線程架構，所有的讀寫操作都是在一條主線程中完成的。當Redis用于高并發(fā)場景時，這條線程就變成了它的生命線。如果出現(xiàn)阻塞，哪怕是很短時間，對于應用來說都是噩夢。

　　導致阻塞問題的原因：

• 內(nèi)在原因：不合理地使用API或數(shù)據(jù)結構、CPU飽和、持久化阻塞等
• 外在原因：CPU競爭、內(nèi)存交換、網(wǎng)絡問題等

　　一、發(fā)現(xiàn)阻塞

• 應用方加入異常監(jiān)控，如日志系統(tǒng)，比如Java語言中的logback或log4j
• Redis監(jiān)控系統(tǒng)，如CacheCloud

　　二、內(nèi)在原因

　　1.API或數(shù)據(jù)結構使用不合理

　　通常Redis執(zhí)行命令速度非常快，但是，如果對一個包含上萬個元素的hash結構執(zhí)行hgetall操作，由于數(shù)據(jù)量比較大且命令算法復雜度是O(n)，這條命令執(zhí)行速度必然很慢。

　　對于高并發(fā)的場景應該盡量避免在大對象上執(zhí)行算法復雜度超過O(n)的命令。

　　（1）如何發(fā)現(xiàn)慢查詢

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

　　（2）發(fā)現(xiàn)慢查詢后如何調(diào)整

• 修改為低算法復雜度的命令
• 調(diào)整大對象：縮減大對象數(shù)據(jù)或把大對象拆分為多個小對象，防止一次命令操作過多的數(shù)據(jù)。大對象拆分過程需要視具體的業(yè)務決定，如用戶好友集合存儲在Redis中，有些熱點用戶會關注大量好友，這時可以按時間或其他維度拆分到多個集合中。

　　（3）如何發(fā)現(xiàn)大對象

bigjun@myubuntu:~$ redis-cli -h 192.168.131.130 -p 6379 --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 'XML' with 180 bytes [00.00%] Biggest list found so far 'hot:user:list' with 5 items-------- summary -------Sampled 12 keys in the keyspace! Total key length in bytes is 108 (avg len 9.00)Biggest string found 'XML' has 180 bytes Biggest list found 'hot:user:list' has 5 items11 strings with 480 bytes (91.67% of keys, avg size 43.64) 1 lists with 5 items (08.33% of keys, avg size 5.00) 0 sets with 0 members (00.00% of keys, avg size 0.00) 0 hashs with 0 fields (00.00% of keys, avg size 0.00) 0 zsets with 0 members (00.00% of keys, avg size 0.00) 0 streams with 0 entries (00.00% of keys, avg size 0.00)

　　2.CPU飽和

　　單線程的Redis處理命令時只能使用一個CPU。而CPU飽和是指Redis把單核CPU使用率跑到接近100%。使用top命令很容易識別出對應Redis進程的CPU使用率。CPU飽和是非常危險的，將導致Redis無法處理更多的命令，嚴重影響吞吐量和應用方的穩(wěn)定性。對于這種情況，首先判斷當前Redis的并發(fā)量是否達到極限，建議使用統(tǒng)計命令redis-cli -h {ip} -p {port} --stat獲取當前Redis使用情況

bigjun@myubuntu:~$ redis-cli -h 192.168.131.130 -p 6379 --stat ------- data ------ --------------------- load -------------------- - child - keys mem clients blocked requests connections 12 851.05K 2 0 506 (+0) 15 12 851.05K 2 0 507 (+1) 15 12 851.05K 2 0 508 (+1) 15 12 851.05K 2 0 509 (+1) 15 12 851.05K 2 0 510 (+1) 15 12 851.05K 2 0 511 (+1) 15 12 851.05K 2 0 512 (+1) 15 12 851.05K 2 0 513 (+1) 15 12 851.05K 2 0 514 (+1) 15
...

　　然后根據(jù)info commandstats統(tǒng)計信息分析出命令不合理開銷時間：

192.168.131.130:6379> info commandstats # Commandstats cmdstat_type:calls=12,usec=3,usec_per_call=0.25 cmdstat_scan:calls=2,usec=17,usec_per_call=8.50 cmdstat_monitor:calls=1,usec=1,usec_per_call=1.00 cmdstat_del:calls=1,usec=70,usec_per_call=70.00 cmdstat_mset:calls=1,usec=34,usec_per_call=34.00 cmdstat_replconf:calls=398,usec=985,usec_per_call=2.47 cmdstat_llen:calls=1,usec=0,usec_per_call=0.00 cmdstat_script:calls=7,usec=809,usec_per_call=115.57 cmdstat_incr:calls=5,usec=33,usec_per_call=6.60 cmdstat_rpush:calls=1,usec=41,usec_per_call=41.00 cmdstat_dbsize:calls=1,usec=1,usec_per_call=1.00 cmdstat_client:calls=12,usec=189,usec_per_call=15.75 cmdstat_bgsave:calls=1,usec=296,usec_per_call=296.00 cmdstat_get:calls=9,usec=95,usec_per_call=10.56 cmdstat_eval:calls=11,usec=90262859,usec_per_call=8205714.00 cmdstat_lrange:calls=3,usec=114,usec_per_call=38.00 cmdstat_set:calls=3,usec=63,usec_per_call=21.00 cmdstat_keys:calls=10,usec=409,usec_per_call=40.90 cmdstat_strlen:calls=11,usec=15,usec_per_call=1.36 cmdstat_save:calls=1,usec=1410,usec_per_call=1410.00 cmdstat_evalsha:calls=1,usec=20,usec_per_call=20.00 cmdstat_info:calls=14,usec=1005,usec_per_call=71.79 cmdstat_ping:calls=4,usec=5,usec_per_call=1.25 cmdstat_command:calls=2,usec=560,usec_per_call=280.00 cmdstat_mget:calls=2,usec=18,usec_per_call=9.00 cmdstat_psync:calls=1,usec=1608,usec_per_call=1608.00

　　3.持久化阻塞

　　對于開啟了持久化功能的Redis節(jié)點，需要排查是否是持久化導致的阻塞。

• fork阻塞：ork操作發(fā)生在RDB和AOF重寫時，Redis主線程調(diào)用fork操作產(chǎn)生共享內(nèi)存的子進程，由子進程完成持久化文件重寫工作。如果fork操作本身耗時過長，必然會導致主線程的阻塞。
• AOF刷盤阻塞：當我們開啟AOF持久化功能時，文件刷盤的方式一般采用每秒一次，后臺線程每秒對AOF文件做fsync操作。當硬盤壓力過大時，fsync操作需要等待，直到寫入完成。如果主線程發(fā)現(xiàn)距離上一次的fsync成功超過2秒，為了數(shù)據(jù)安全性它會阻塞直到后臺線程執(zhí)行fsync操作完成。這種阻塞行為主要是硬盤壓力引起。
• HugePage寫操作阻塞：子進程在執(zhí)行重寫期間利用Linux寫時復制技術降低內(nèi)存開銷，因此只有寫操作時Redis才復制要修改的內(nèi)存頁。對于開啟Transparent HugePages的操作系統(tǒng)，每次寫命令引起的復制內(nèi)存頁單位由4K變?yōu)?MB，放大了512倍，會拖慢寫操作的執(zhí)行時間，導致大量寫操作慢查詢。

　　三、外在原因

　　1.CPU競爭

• 進程競爭：Redis是典型的CPU密集型應用，不建議和其他多核CPU密集型服務部署在一起。當其他進程過度消耗CPU時，將嚴重影響Redis吞吐量。可以通過top、sar等命令定位到CPU消耗的時間點和具體進程，這個問題比較容易發(fā)現(xiàn)，需要調(diào)整服務之間部署結構。
• 綁定CPU：部署Redis時為了充分利用多核CPU，通常一臺機器部署多個實例。常見的一種優(yōu)化是把Redis進程綁定到CPU上，用于降低CPU頻繁上下文切換的開銷。這個優(yōu)化技巧正常情況下沒有問題，但是存在例外情況，當Redis父進程創(chuàng)建子進程進行RDB/AOF重寫時，如果做了CPU綁定，會與父進程共享使用一個CPU。子進程重寫時對單核CPU使用率通常在90%以上，父進程與子進程將產(chǎn)生激烈CPU競爭，極大影響Redis穩(wěn)定性。因此對于開啟了持久化或參與復制的主節(jié)點不建議綁定CPU。

　　2.內(nèi)存交換

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

　　（1）識別內(nèi)存交換：

bigjun@myubuntu:~$ redis-cli -h 192.168.131.130 -p 6379 info server | grep process_id process_id:2668root@myubuntu:~# cat /proc/2668/smaps | grep Swap Swap: 0 kB SwapPss: 0 kB Swap: 0 kB SwapPss: 0 kB Swap: 0 kB SwapPss: 0 kB Swap: 0 kB SwapPss: 0 kB ...

　　（2）預防內(nèi)存交換：

• 保證機器充足的可用內(nèi)存。
• 確保所有Redis實例設置最大可用內(nèi)存（maxmemory），防止極端情況下Redis內(nèi)存不可控的增長。
• 降低系統(tǒng)使用swap優(yōu)先級。

　　3.網(wǎng)絡問題

　　（1）連接拒絕

• 網(wǎng)絡閃斷（網(wǎng)絡割接或者帶寬耗盡）
• Redis連接拒絕（超過客戶端最大連接數(shù)）
• 連接溢出（進程限制或backlog隊列溢出）

　　（2）網(wǎng)絡延遲

　　網(wǎng)絡延遲取決于客戶端到Redis服務器之間的網(wǎng)絡環(huán)境。主要包括它們之間的物理拓撲和帶寬占用情況。常見的物理拓撲按網(wǎng)絡延遲由快到慢可分為：同物理機>同機架>跨機架>同機房>同城機房>異地機房。但它們?nèi)轂男哉孟喾?#xff0c;同物理機容災性最低而異地機房容災性最高。

　　網(wǎng)絡延遲問題經(jīng)常出現(xiàn)在跨機房的部署結構上，對于機房之間延遲比較嚴重的場景需要調(diào)整拓撲結構，如把客戶端和Redis部署在同機房或同城機房等。
　　帶寬瓶頸通常出現(xiàn)在以下幾個方面：

• 機器網(wǎng)卡帶寬。
• 機架交換機帶寬。
• 機房之間專線帶寬。

　　（3）網(wǎng)卡軟中斷

　　網(wǎng)卡軟中斷是指由于單個網(wǎng)卡隊列只能使用一個CPU，高并發(fā)下網(wǎng)卡數(shù)據(jù)交互都集中在同一個CPU，導致無法充分利用多核CPU的情況。網(wǎng)卡軟中斷瓶頸一般出現(xiàn)在網(wǎng)絡高流量吞吐的場景。

轉載于:https://www.cnblogs.com/BigJunOba/p/9136099.html

總結

以上是生活随笔為你收集整理的Redis（七）Redis的噩梦：阻塞的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。