背景

redis-K,V數據庫，因其高性能的操作性和支持豐富的數據結構，目前大量被用于銜接應用層和關系數據庫中間的緩存層。

隨著使用的場景越來越多，和數據量快速的遞增，在生產環境中經常會遇到相關的性能瓶頸問題。

這時候就需要借助一些外部的手段來分析瓶頸根源在哪，對癥下藥提升性能。

常見性能問題及問題分析過程

1、生產系統剛開始運行階段，系統穩定。但是運行一段時間后，發現部分時間段系統接口響應變慢。查看客戶端日志經常會出現這樣的錯誤：

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out。

2、生產環境長時間的運行后，經常會有接口返回數據失敗的情況，或者是從監控上發現數據庫壓力某一時間暴增。查看客戶端日志發現這樣的錯誤：

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

3、突然間服務不能訪問，返回錯誤：

redis.clients.jedis.exceptions.JedisDataException: MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.

當然在實際生產情況中，還有各種各樣的異常情況，但是在客戶端普遍表現為上面幾種場景，下面我們來一步步分析上面的問題。

問題一

首先從客戶端反饋的日志，懷疑是服務器和客戶端間的網絡問題。為排除這個問題，我們編寫腳本，在客戶端定時ping服務端（redis服務），持續運行一段后，發現未有丟包的情況，排除網絡問題。

查看redis服務端日志，未發現有異常情況。查看redis服務器資源監控，發現每幾分鐘左右，IO會有一波峰值，但是CPU和帶寬壓力都在正常范圍。

這里介紹下我們的redis部署模式：一主一從通過redis自帶的sentinal做HA，主從均有開啟持久化。初步懷疑間隔性IO操作占用資源導致redis讀寫變慢(在此，拋出一個問題：在服務器資源CPU和帶寬均未達到瓶頸的情況下，持續的IO高峰操作是否會影響物理內存的讀寫）。接下來采取的措施是：關閉主庫的持久化，用從庫來做持久化，但是這種模式下存在一個問題，如果主發生故障，sentinal做主從切換后問題同樣存在，大家有更好的建議可以指點下。

運行一段時候，發現問題有所改善，但是依然還是會有time out的情況，只有繼續排查問題。由于redis操作采用單線程，考慮會不會有某些慢查詢導致time out。執行slowlog查看慢查詢語句，發現有大量的keys命令操作，keys命令在大量并發情況下性能非常差，結合官方給出的warning

正式環境中，盡量避免使用keys，接下來找出使用keys的代碼做優化，至此，time out問題解決。

問題二

從錯誤日志看，是提示無法獲取連接。有兩種情況：

1、客戶端的連接池滿了，無法創建新的連接

檢查客戶端連接最大限制maxActive是否足夠

2、redis服務端連接溢出，無法分配新的連接

檢查服務端tcp連接：netstat -nat|grep -i "6379"|wc -l

檢查服務端連接是否達到最大值：查看服務端支持的最大連接：CONFIG?GET?maxclients，查看當前服務端建立的 ? 連接：connected_clients

通過上述檢查后，發現redis服務端connected_clients連接數持續過高，經常在最大值徘徊。但是結合客戶端配置的最大連接配置maxActive，計算出所有客戶端連接占滿的情況下最大的連接數也達不到connected_clients的連接數。

執行client list命令，發現大量的client的idle時間特別長：

正常的client連接，在持續使用的情況下，是不可能空閑這么長時間，連接長時間空閑，客戶端也會關閉連接。

查看redis服務端下面兩項配置：

• timeout：client連接空閑多久會被關閉（這個配置容易被誤導為：連接超時和操作執行超時）
• tcp-keepalive：redis服務端主動向空閑的客戶端發起ack請求，以判斷連接是否有效

檢查上述配置發現 timeout和tcp-keepalive均未啟用（均為0），這種情況下，redis服務端沒有有效的機制來確保服務端已經建立的連接是否已經失效。當服務器和客戶端網絡出現閃斷，導致tcp連接中斷，這種情況下的client將會一直被redis服務端所持有，就會出現上面我們看到的idle時間特長的client連接。

接下來設置timeout和tcp-keepalive來清理失效的連接。

上面問題中提到的數據庫某一時間壓力暴增，是由于在緩存模式下，redis請求失敗，請求的壓力瞬間集中到數據庫。

問題三

從錯誤提示，可以看出是向磁盤保存數據失敗。引起這個問題的原因一般是內存不足，但是生產環境我們一般都會為系統分配足夠的內存運行，而且查看內存情況也顯示還有可用內存。

查看redis日志，發現有這個錯誤：Can’t save in background: fork: Cannot allocate memory

redis在保存內存的數據到磁盤時，為了防止主進程假死，會Fork一個子進程來完成這個保存操作。但是這個Fork的子進程會需要分配和主進程相同的內存，這時候就相當于需要的內存double了，如果這時候可用內存不足以分配需要的內存，將會導致Fock子進程失敗而無法保存數據到磁盤。

修改linux內核參數：vm.overcommit_memory=1。至此，問題解決。

overcommit_memory有三種取值：0， 1， 2

• 0：:檢查是否有足夠的可用內存供進程使用；有則允許申請，否則，內存申請失敗，并把錯誤返回給應用進程；
• 1：表示內核允許分配所有的物理內存，而不管當前的內存狀態如何；
• 2：表示內核允許分配超過所有物理內存和交換空間總和的內存。

優化措施總結

1、結合實際使用場景，考慮是否需要用到redis的持久化，如果單純用來做應用層的緩存（在緩存未命中的情況下訪問數據庫），可以關閉持久化。

2、緩存模式下，盡量為每塊緩存設置時效性，避免冷數據長時間占用資源。

3、生產環境中盡量避免使用keys操作，由于redis是單線程模式，大量的keys操作會阻塞其他的命令執行。

4、設置合理的內存回收策略，保證內存可用性的同時能適當的提供緩存的命中率。

5、提前計算出系統可能會用的內存大小，合理的分配內存。需要注意在開啟持久化模式下，需要預留更多的內存提供給Fock的子進程做數據磁盤flush操作。

深入探討研究

如果redis服務端未設置timeout，客戶端會如何處理長時間未使用的連接？

這個問題可以從分析redis的sdk源碼查找答案，不過這個過程會比較枯燥。

接下來我們直接通過抓取客戶端和服務端的tcp數據包來獲取答案：

這里我用wireshark來抓取中間的tcp數據包，下面是抓取了一個完整的redis連接（從發起到結束）的tcp數據包

從上面可以看到，從tcp3次握手建立連接，到最后客戶端發送reset包給服務端終止了這個連接。

追蹤整個tcp的數據流：

*2$4AUTH$8password+OK*1$4PING+PONG*1$4PING+PONG*1$4QUIT+OK

從tcp數據流可以看出，整個tcp連接中間經歷的操作：

1、客戶端發送密碼建立連接，服務端響應OK

2、客戶端發送PING命令校驗連接，服務端響應PONG表示成功

3、客戶端再次發送PING命令校驗連接，服務端響應PONG表示成功

4、客戶端發送QUIT命令退出連接，服務端響應OK表示退出成功

當服務端響應QUIT命令OK后，客戶端發送RESET的tcp包終止整個tcp連接。中間客戶端發起了兩次PING命令校驗連接和一次QUIT命令來退出連接，每次間隔30s，加起來整個連接存活了90s。

總結