1. 發現阻塞
客戶端記錄redis相關日誌時，需要具體到redis節點，在出現連線相關異常時能定位的具體節點。
伺服器端應利用相關工具加強對redis集群的監控，發現不正常指標時應進行報警，並快速反應。主要監控指標為慢查詢、持久化阻塞、連線拒絕、cpu記憶體網路磁碟使用過載。
阻塞出現的原因主要包括內在原因和外在原因2方面。
2. 內在原因
2.1 api或資料結構使用不合理
通常redis執行指令的速度非常快，但有些指令如hgetall在遇到大併發且大物件時，執行速度會變慢。因此在高併發場景，避免在大物件上執行演算法複雜度高的指令。
如何發現慢查詢？如何發現大物件？
slowlog get 獲取最近的n條慢查詢指令。
redis-cli-h-pbigkeys指令，彙總大物件的鍵以及不同型別資料結構的使用情況。
解決方案：
避免使用複雜度高的指令
根據業務合理調整大物件，將大物件拆分成多個小物件
如果使用管道，減少管道指令數量，如果使用批量操作，減少批量操作的數量
2.2 cpu飽和
redis是乙個單執行緒架構，處理命令只會用乙個cpu，可以使用redis-cli -h -p --stat獲取redis使用情況。如下圖所示：
上圖的併發量達到6w+，優化餘地不大，可以考慮擴容。如果只有幾百幾千的併發量redis的cpu就接近飽和是很不正常的。
有可能是因為過度的記憶體優化，導致cpu執行指令變慢，如使用info commandstats統計指令的開銷時間，如下所示：
hset指令平均執行時間為135毫秒，肯定不合理，有可能是redis過度放寬了ziplist的使用，如調大了hash-max-ziplist-entries和hash-max-ziplist-value配置，ziplist編碼省空間，但執行效率會比hashtable低。
2.3 持久化阻塞
fork阻塞：在rdb和aof重寫時，redis主線程會開啟乙個fork子程序，由子程序完成持久化操作，可以通過info stats獲取到latest_fork_usec指標，如果超過1秒，則需要作出優化調整。
aof刷盤阻塞：開啟aof後，後台執行緒每秒對aof檔案做同步，如果同步超過2秒，redis會阻塞等待。也可以檢視info persistence統計中的aof_delayed_fsync指標。
hugepage寫操作阻塞：具體見學習筆記8
3. 外在原因
3.1 cpu競爭
redis是cpu密集型應用，不建議和其它cpu密集服務部署在一起，因為其它cpu密集服務可能會與redis競爭cpu，可通過top、sar等命令定位cpu消耗的時間點和具體程序。
如果把redis程序繫結到cpu上，可用於降低cpu上下文切換，但如果開啟了持久化，那麼fork程序會和redis程序競爭cpu，因此對於開啟了持久化或參與複製的節點不要繫結cpu。
3.2 記憶體交換
redis高效能的保證是所有資料都在記憶體中，如果redis的部分記憶體是虛擬記憶體（磁碟），那麼效能急速下降，可通過如下辦法查詢：
獲取redis程序號： redis-cli -p 6383 info server | grep process_id
根據程序號查詢記憶體交換資訊：cat /proc/4476/smaps | grep swap
如果為0，則表示記憶體沒有被交換，預防方法如下：
保證機器有足夠的可用記憶體。
設定redis例項最大可用記憶體即maxmemory，防止redis記憶體不可控的增長
降低系統使用swap優先順序
3.3 網路問題
3.2.1 連線拒絕
網路問題：盡量避免讓redis和客戶端異地跨機房呼叫。
連線數控制：通過redis的maxclients控制客戶端最大連線數，info stats指令的rejected_connections指標記錄被拒絕的連線。
程序限制：使用linux的ulimit -n檢視系統對請求併發的控制，一般這個值需要調大，如ulimit -n 65535
linux作業系統請求佇列限制：backlog佇列溢位，作業系統對於特定埠的tcp連線使用backlog佇列儲存。修改redis的tcp-backlog引數，預設為511，這個引數可以理解為redis在作業系統層面能接收到的請求佇列長度。可以使用指令netstat -s |grep overflowed 檢視是否出現佇列溢位情況
3.2.2 流量監控
主要是指頻寬不能滿足高併發的要求，如機器網絡卡頻寬、交換機頻寬、專線頻寬等。頻寬占用主要根據當時使用率是否達到瓶頸有關，如頻繁操作redis的大物件對於redis所在的機器很容易達到網絡卡瓶頸，因此需要重點監控機器流量。
3.2.3 網絡卡軟中斷
網絡卡軟中斷是指由於單個網絡卡佇列只能使用乙個cpu，高併發下網絡卡數，據互動都集中在同乙個cpu，導致無法充分利用多核cpu的情況。網絡卡軟中斷瓶頸一般出現在網路高流量吞吐的場景，如下使用「top+數字1」命令可以很明顯看到cpu1的軟中斷指標（si）過高：
《Redis開發與運維》學習筆記 阻塞
redis是典型的單執行緒架構，所有的讀寫操作都是在一條主線程中完成的。當redis用於高併發場景時，這條執行緒就變成了它的生命線。如果出現阻塞，哪怕是很短時間，對於應用來說都是噩夢。導致阻塞問題的原因 通常redis執行命令速度非常快，但是，如果對乙個包含上萬個元素的hash結構執行hgetall...
Redis 學習筆記7 虛擬記憶體
虛擬記憶體是用來將記憶體中不經常使用的資料交換到檔案中，騰出寶貴的記憶體空間，留個經常訪問的資料使用。redis沒有使用os的虛擬記憶體 1 os的虛擬記憶體最小單位為4k而redis物件一般遠遠小於4k。這樣一般會造成乙個os頁上有多個物件，如果只有少數物件比較活躍，os會認為每個os頁比較活躍，...
redis學習筆記（7） 壓縮字典zipmap
在hashtable實現中，redis引入了zipmap資料結構，保證在hashtable剛建立以及元素較少時，用更少的記憶體來儲存，同時對查詢的效率也不會受太大的影響。zipmap利用字串實現了簡單的hash表，來儲存少量key value對。zipmap的記憶體布局如下 1 zmlen 1個位元...