本文爲轉載：
https://blog.csdn.net/vcbin/article/details/53941682
問題描述
系統背景：大型線上Java服務集羣（活躍用戶數上千萬），業務重度使用Redis存儲個管理Session，業務併發量>1WQPS,基本上每個請求都需要訪問Redis(可能是多次），使用了AWS的Redis服務
Redis在平時正常流量下平均響應時間是1-2ms，但是在系統峯值流量上來後Redis在這種情況下平均響應延時會超過20ms，在130萬的並發現會延時達到30ms左右，嚴重影響了整個系統的吞吐量和性能，系統會卡死甚至最嚴重的情況下會JVMCrash
問題排查
- 第一步：快速緩解問題
因爲線上業務嚴重受到影響，首先採用了最快速可以緩解問題的辦法：升級AWS中Redis的實例，從m3.2xlarge升級到了r3.2xlarge，高峯時平均響應延時從20ms降到了18ms，但只是簡單緩解了問題，系統在高峯期的卡死現象還是偶爾會出現（只是次數減少了）
- 第二步：排查問題根源，徹底解決問題
展開對Redis的詳細的問題排查，排查的方向分爲以下三個：
1. 業務端是否有很多不合理的Redis請求
研究發現Redis在服務器端 new connection/s: 100左右， new commands/s 70000 左右，commands/per connection 700左右，研究發現使用pipeline比較多，可以考慮使用mget命令。發現這並不是問題的根源。
2. Redis服務器本身有性能問題
可以參考以下鏈接（蘑菇先生的博客）：https://www.cnblogs.com/mushroom/p/4738170.html
- 我們查詢Redis的slowlog get，沒有特別大的發現（只有一個17ms的慢查詢）
- 進一步查看，發現Redis響應慢時，Redis服務器的網絡輸出帶寬接近1G。懷疑這個是瓶頸，分析發現我們用的AWS實例支持10G的上線，也排除了這個可能性
3. 業務集羣中用到的Redis客戶端：Jedis
- JedisShardedPool maxConnection只設置爲128， 懷疑併發比較大Jedis連接不夠用了，調整爲256試試看結果，發現結果並不明顯（Redis服務器本身並不是多線程去相應服務的，一味的加大客戶端的併發並不會有效解決的問題），只要自己Jedis連接數能和業務最大併發匹配就可以了
- 網上找中文文章沒什麼可以參考的經驗，最後索性開始看Jedis的英文文檔，看看是不是哪些性能相關的參數，我們主要設置的參數有：MaxTotal 96, MaxIdle=64, testOnBorrow=true。 testOnBorrow是指每次Jedis在跟Redis服務器發起請求之前會先發一個test命令去檢查Redis是否準備就緒，主要來應對網絡和服務器不穩定性的，這平白無故的把Jedis對後臺的併發翻了個倍。我們用的是成熟的AWS Redis服務，而且是內網訪問，這些testOnBorrow請求完全是多餘的。所以果斷的改成testOnBorrow=false。見證奇蹟的時刻，修改後觀察系統在業務高峯情況下穩穩當當，Redis的響應最多也就5ms，平均恢復到2ms。問題搞定
- 同時居安思危，我們也發現了系統性能瓶頸的隱患，如果我們的業務再翻個倍，redis這塊會繼續成爲瓶頸。所以我開始着手後續第三部的改造。
- 第三步：長治久安：引入RedisCluster方案，把系統的緩存提升到>15WQPSLevel
這裏我們主要進行了兩個大的改造：
1. 首先從業務上把Redis進行拆分，根據業務類型把需要存儲在之前一個Redis庫的數據拆分成了4個Redis庫。這樣每個庫都可以抗接近7W的QPS了
2. 針對負載最重的Redis庫（Session庫），在AWS上升級爲集羣方案，也把我們客戶端的Jedis改造成JedisCluster客戶端。最後驗證下來AWS的Redis集羣可以最少支持15W+的QPS，平均響應時間能保證在2ms左右
3. 把一些批量的Redis操作，使用Jedis的pipeline方式減小併發度
最後的勝利：經過這一輪改造，我們的緩存模塊一直平穩運行了快2年了，系統的流量最少也翻了6-7倍，這個Redis方案依然穩穩的。老闆再也不用擔心宕機問題了。
經驗總結
1. 遇到線上問題，不能慌了手腳，要先快速的緩解問題，幫組正式分析和正式方案上線爭取寶貴時間（那段時間高峯期經常宕機重啓，確實捏了一把冷汗啊）
2. 解決問題時（特別是當沒有頭緒時），還是要從全局出發，理清楚思路，從各個可能出問題的模塊逐一去分析排查，抽絲剝繭總能找出根源並制定解決方案
3. 居安思危，出了問題要想想將來系統發展更大後是否有類似的隱患，早點進行重構改造，做到長治久安。