前言

簡單整理一下客戶端案例分析。

正文

現象一:

服務端現象：Redis主節點記憶體陡增，幾乎用滿maxmemory，而從節點 記憶體並沒有變化。

客戶端現象：客戶端產生了OOM異常，也就是Redis主節點使用的記憶體 已經超過了maxmemory的設定，無法寫入新的資料.

2.分析原因

1）確實有大量寫入，但是主從複製出現問題：查詢了Redis複製的相關 資訊，複製是正常的，主從資料基本一致。

2）其他原因造成主節點記憶體使用過大：排查是否由客戶端緩衝區造成 主節點記憶體陡增，使用info clients命令查詢相關資訊如下：

很明顯輸出緩衝區不太正常，最大的客戶端輸出緩衝區佇列已經超過了 20萬個物件，於是需要通過client list命令找到omem不正常的連線，一般來 說大部分客戶端的omem為0（因為處理速度會足夠快），於是執行如下代 碼，找到omem非零的客戶端連線：

redis-cli client list | grep -v "omem=0"

已經很明顯是因為有客戶端在執行monitor命令造成的。

3.處理方法和後期處理

只要使用client kill命令殺掉這個連 接，讓其他客戶端恢復正常寫資料即可。但是更為重要的是在日後如何及時 發現和避免這種問題的發生，基本有三點：

1. 從運維層面禁止monitor命令，例如使用rename-command命令重置 monitor命令為一個隨機字串，除此之外，如果monitor沒有做rename- command，也可以對monitor命令進行相應的監控

2. 從開發層面進行培訓，禁止在生產環境中使用monitor命令，因為有時 候monitor命令在測試的時候還是比較有用的，完全禁止也不太現實。

3. 限制輸出緩衝區的大小。

4. 使用專業的Redis運維工具,上述問題在 Cachecloud中會收到相應的報警，快速發現和定位問題

現象二:

客戶端週期性的超時

客戶端現象：客戶端出現大量超時，經過分析發現超時是週期性出現的.

服務端現象：服務端並沒有明顯的異常，只是有一些慢查詢操作

原因:

·網路原因：服務端和客戶端之間的網路出現週期性問題，經過觀察網 絡是正常的。

·Redis本身：經過觀察Redis日誌統計，並沒有發現異常。

客戶端：由於是週期性出現問題，就和慢查詢日誌的歷史記錄對應了 一下時間，發現只要慢查詢出現，客戶端就會產生大量連線超時，兩個時間點基本一致.

最終找到問題是慢查詢操作造成的，通過執行hlen發現有200萬個元 素，這種操作必然會造成Redis阻塞，通過與應用方溝通了解到他們有個定 時任務，每5分鐘執行一次hgetall操作。

hlen user_fan_hset_sort

以上問題之所以能夠快速定位，得益於使用客戶端監控工具把一些統計 資料收集上來，這樣能更加直觀地發現問題，如果Redis是黑盒執行，相信 很難快速找到這個問題。處理線上問題的速度非常重要。

處理方法和後期處理:

這個問題處理方法相對簡單，只需要業務方及時處理自己的慢查詢即 可，但是更為重要的是在日後如何及時發現和避免這種問題的發生，基本有三點:

1. ·從運維層面，監控慢查詢，一旦超過閥值，就發出報警。

2. ·從開發層面，加強對於Redis的理解，避免不正確的使用方式。

3. ·使用專業的Redis運維工具

總結

1. RESP（Redis Serialization Protocol Redis）保證客戶端與服務端的正 常通訊，是各種程式語言開發客戶端的基礎。

2. 客戶端輸入緩衝區不能配置，強制限制在1G之內，但是不會受到 maxmemory限制

3. 客戶端輸出緩衝區支援普通客戶端、釋出訂閱客戶端、複製客戶端 配置，同樣會受到maxmemory限制。

4. Redis的timeout配置可以自動關閉閒置客戶端，tcp-keepalive引數可 以週期性檢查關閉無效TCP連線

5. monitor命令雖然好用，但是在大併發下存在輸出緩衝區暴漲的可能性

6. info clients幫助開發和運維人員找到客戶端可能存在的問題。

7. 理解Redis通訊原理和建立完善的監控系統對快速定位解決客戶端 常見問題非常有幫助

結

下一大節， 持久化相關知識。