redis其他問題

現在業務上每天有5億+的請求，平時redis的操作在2k+每秒左右。到了高峰有3k+，這時候用戶端就會頻繁的報connect time out的異常。

但是，資料上說redis可以達到10w每秒。3k遠遠不到w這個級别啊，請問有什麼建議優化現在的情況麼？

答：

redis連接配接數有多少？是否超過了max open files的限制？

直接top看看redis是否跑滿cpu等等。

還有逾時時間配置多少等等。

答：你可以把你應用的部署環境描述下，使用什麼樣的用戶端，長連接配接還是短連接配接，redis是單機環境還是叢集環境，redis是否配置了持久化，什麼樣的持久化方式，還有就是redis伺服器的硬體設施，把這些描述清楚然後再分析原因。

最近剛在一個大型活動中大量使用了redis，前幾次線上高并發模拟的确出現了類似題主的問題。修正方式有二：

1.伺服器對tcp和http的限制（直接拒絕或逾時）

2.redis對并發數的限制（maxclients參數，once the limit is reached redis will close all the new connections sending an error 'max number of clients reached'.）

對了，我的平台是windows+.net+redis(servicestack)

redis 使用了單線程的設計， 意味着單線程服務于所有的用戶端請求，使用一種複用的技術。這種情況下redis可以在任何時候處理單個請求， 是以所有的請求是順序處理的。這和node.js的工作方式很像， 所有的産出通常不會有慢的感覺，因為處理單個請求的時間非常短，但是最重要的是這些産品被設計為非阻塞系統調用，比如從套接字中讀取或寫入資料。

我提到過redis從2.4版本後幾乎是單線程的，我們使用線程在背景運作一些效率低下的i/o操作， 主要關系到硬碟i/o，但是這不改變redis使用單線程處理所有請求的事實。

總結：就是reids本身性能沒有問題，處理并發能力ok，就是跨伺服器遠端通路其他伺服器reids時，并發大了，網絡延遲等，會出現取reids卡死。