關於redis在高併發下的效能分析

前言：

最近上手了一個項目，我負責這個專案的架構設計與實作。原本公司做了很多給公司以外的人使用的API，但是在外人使用的時候，接口的鏈接是怎樣就給別人怎麼樣，沒有加密也沒有做並發控制，接口程序所在的機器在哪，給別人的IP就在哪，而且沒有平台進行管理。因此我清楚知道，這些介面的價值很難被發現（哪個介面別人用的比較多，哪個介面別人用的比較少）。

僅僅針對」監控「的這項需求，我們引入了redis作為中間層，首先我們完善了使用者使用介面的註冊流程，透過使用者資訊和位址，hash出一個key，這個key是對應著一個地址的，把這個（key - 地址）對存在了redis裡面。其次是nginx，nginx在我們的專案裡面的流程大概是這樣：

1、用戶註冊之後獲取到他的key，透過包含了key的跟原本的url完全不同的url來訪問

2、nginx捕捉到使用者特殊的key，然後程式根據這個key從redis中取出目標位址，再由nginx取代使用者存取真正的位址，繼而回傳。

（這個過程好處是很多的）

（1）、隱藏了真實的地址，程序可以在上游伺服器之外的地方乾預用戶的訪問，提高安全性，幹預過程可以很複雜

（2）、獲取用戶的信息，並將其存回redis，上游伺服器透過定時程序將存在redis中的日誌持久化進oracle並刪除，然後進一步分析和可視化

問題來了

這個專案還處於測試階段，資源是一台window server 伺服器，和centos6.5伺服器，測試階段10秒內大概有10萬的並發量，剛部署上去的一兩天還是沒有問題的，接下來卻出現了redis連線不上的狀況。查看進程訪問，會出現下面的情況。 （window server 下）

出現很多FiN_WAIT_2的TCP連結。

（學習影片分享：redis影片教學）

分析

#一、redis是使用單一執行緒處理連線的，表示它絕對會出現下面二所說的情況。

二、很明顯這是由於nginx和redis之間有很多沒有釋放的資源造成的，查看這個TCP的狀態FIN_WAIT_2，解釋一下：

在HTTP應用中，存在一個問題，SERVER由於某種原因關閉連接，如KEEPALIVE的超時，這樣，作為主動關閉的SERVER一方就會進入FIN_WAIT2狀態，但TCP/IP協議棧有個問題，FIN_WAIT2狀態是沒有超時的（不像TIME_WAIT狀態），所以如果CLIENT不關閉，這個FIN_WAIT_2狀態將保持到系統重新啟動，越來越多的FIN_WAIT_2狀態會致使核心crash。

好吧，大學沒有好好唸書，以下是http連線的狀態變化

客戶端狀態遷移

CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1 ->FIN_WAIT_2->TIME_WAIT->CLOSEDb.

服務器狀態遷移

CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT-> LAST_ACK->CLOSED

有缺陷的客戶端與持久連線

有一些客戶端在處理持久連線(akakeepalives)時存在問題。當連線空閒下來伺服器關閉連線時(基於KeepAliveTimeout指令)，

客戶端的程式編制使它不會傳送FIN和ACK回伺服器。這樣就意味著這個連接將停留在FIN_WAIT_2狀態直到以下之一發生：

客戶端為同一個或不同的站點打開新的連接，這會使它在該個套接字上完全關閉以前的連接。

使用者退出客戶端程序，這樣在一些(也許是大多數？)客戶端上會使作業系統完全關閉連線。

FIN_WAIT_2逾時，在那些具有FIN_WAIT_2狀態逾時設定的伺服器上。

如果你夠幸運，這意味著那些有缺陷的客戶端會完全關閉連線並釋放你伺服器的資源。

然而，有一些情況下套接字永遠不會完全關閉，例如撥號客戶端在關閉客戶端程式之前從ISP斷開。

此外，有的客戶端有可能空置好幾天不創建新連接，並且這樣在好幾天裡保持著套接字的有效即使已經不再使用。這是瀏覽器或作業系統的TCP實作的Bug。

　　產生原因有： 

1、長連接且當連接一直處於IDLE狀態導致SERVERCLOSE時，CLIENT編程缺陷，沒有向SERVER 發出FIN和ACK包 

#2 、APACHE1.1和APACHE1.2增加了linger_close()函數，前面的貼文有介紹，這個函數可能引起了這個問題（為什麼我也不清楚）

　　解決方法： 

1。對FIN_WAIT_2狀態增加逾時機制，這個特性在協定裡沒有體現，但在一些OS中已經實現 

如：LINUX、SOLARIS、FREEBSD、HP-UNIX、IRIX等 

#2。不要用linger_close()編譯 

3。用SO_LINGER代替，這在某些系統中還能很好地處理 

4。增加用於儲存網路連線狀態的記憶體mbuf，以防止核心crash 

5。 DISABLE KEEPALIVE 

針對這種情況，我們做了幾次討論，有些結論，分別是：

1、設定nginx與redis的連接池，keepalive的時間，分別設為10秒，5秒，但是結果還是一樣

2、不用keepalive，即不使用連接池，即每次用完就close()掉，你可以看到連接少了，但是不使用連接池，意味著10秒內要打開關閉10萬次，開銷太大

3、redis集群，在原本集群的體系上添加redis的集群，這或許能解決問題，但是10秒內10萬其實不多，這樣做了或許是取巧，並沒有找到問題

4、設定redis的idle（空閒）時間限制，結果一樣。

解決方案：

實際上不算解決方案，因為放棄了redis的記憶體機制，而是使用nginx本身的記憶體技術。網路上關於redis的優化大部分不適用，這個問題有待分析解決。

相關推薦：redis資料庫教學

以上是關於redis在高併發下的效能分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！