team中的一個同學在其項目中使用了Redis作為緩存，將熱點數據存放在Redis中。為了提升性能，寫Redis時采用了管道的方式，平時使用時，Redis的性能、資源使用都能符合項目需求，但當訪問量增加的時候，Redis的QPS還能滿足要求，但CPU使用率高的時候已經達到90%+，平時只有30%+，而眾所周知，Redis是單進程的，只能占用1個CPU核，跑滿了也就100%，無法利用機器的多核，而當CPU跑到100%時，必然會造成性能瓶頸。怎么解決？

推薦：《Redis視頻教程》

方案一：

首先想到的是，增加Redis服務器的數量，在客戶端對存儲的key進行hash運算，存入不同的Redis服務器中，讀取時，也進行相同的hash運算，找到對應的Redis服務器，可以解決問題，但是不好的地方：

第一，客戶端要改動代碼；

第二、需要客戶端記住所有的Redis服務器的地址；

這個方案可以使用，但能不能不用改動代碼就能實現擴容呢？

方案二：

搭建一個集群，由于Redis服務器使用的版本低于3.0，不支持集群，只能通過使用代理，就想到了有名的Redis代理twemproxy。

twemproxy的性能也是杠杠滴，雖然是代理，但它對訪問性能的影響非常小，連Redis作者都推薦它。

twemproxy使用方便，對于一個新手來說，不到一個小時就能學會使用，而且關鍵是不用改動客戶端代碼，幾乎支持所有的Redis命令和管道操作，只需要改下客戶端的配置文件中配置的Redis的IP和PORT，由原來的Redis的IP和Port改成twemproxy服務的IP和PORT。

客戶端不需要考慮hash的問題，這些twemproxy會做，客戶端就像操作一臺Redis一樣。

上面用了“幾乎”這個詞，因為有些命令，比如"keys *"就不支持

很快部署了好了twemproxy和后面跟著的四個Redis機器，壓測發現，后面的四臺Redis的CPU使用率降下來了，但新問題來了，twemproxy也是單進程的！性能瓶頸又跑到twemproxy上來了！

方案三：

對Redis的訪問分為寫和讀，類似生產者和消費者， 再仔細分析，發現寫的少，讀的相對多些，這就可以將讀寫分離，寫的往主的寫，讀的從備的讀，遇到的情況恰好是讀和寫是兩個服務，做到讀寫分離通過改下配置信息就可以很簡單的做到，，這樣分散了主Redis的壓力。

這里對Redis的訪問壓力有好轉，但不是長久之計，比如遇到舉辦活動， 數據量增大時，還是會有性能的風險。

最終采用的方法是綜合方案二和三，如下圖所示：

這種方法對現有的服務改動最小，可以有效緩解redis壓力的問題

producer端和consumer端的twemproxy使用的hash算法要求一致，不然找不到key了。

如果把方案一也加進來，會比較復雜，暫時用不到。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com