team中的一個同學在其項目中使用了Redis作爲緩存，將熱點數據存放在Redis中。爲了提升性能，寫Redis時採用了管道的方式，平時使用時，Redis的性能、資源使用都能符合項目需求，但當訪問量增加的時候，Redis的QPS還能滿足要求，但CPU使用率高的時候已經達到90%+，平時只有30%+，而衆所周知，Redis是單進程的，只能佔用1個CPU核，跑滿了也就100%，無法利用機器的多核，而當CPU跑到100%時，必然會造成性能瓶頸。怎麼解決？
主從結構 加從的節點提高讀的能力 ，寫入壓力增大
方案一：
首先想到的是，增加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了。
如果把方案一也加進來，會比較複雜，暫時用不到。