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了。
如果把方案一也加進來，會比較複雜，暫時用不到。
#以上是redis怎麼擴容的詳細內容。更多資訊請關注PHP中文網其他相關文章！
