最近一直在跟進storm的問題，從storm集群的穩(wěn)定性到監(jiān)控到升級到bolt寫redis的問題,因為公司目前沒有專業(yè)運維redis的，只能我們數(shù)據(jù)部門自己搞了。。下面記錄下遇到的幾個問題:

目前創(chuàng)新互聯(lián)公司已為1000多家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)站空間、網(wǎng)站托管、企業(yè)網(wǎng)站設計、清豐網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

總結下目前storm寫redis問題:

1.redis高峰寫入異常，增加redis監(jiān)控，發(fā)現(xiàn)cpu性能瓶頸(redis單線程，最高10w/s的處理量)

2.之前redis bolt的并發(fā)在200以上，過多的并發(fā)對redis的性能造成比較大的影響，現(xiàn)在已經(jīng)減少為5

3.關閉了redis的monitor監(jiān)控,常駐的monitor監(jiān)控對redis的性能損耗在30%左右

4.關閉了redis的rdb持久化方式，開啟了aof的方式，在低峰aofrewrite

5.擴容到8個實例，使用jedissharding的方式，高峰時單機超過5W/s處理量

6.去掉select操作，使用默認db0

7.對高峰時的數(shù)據(jù)進行分析，40w/s的處理量中，ping操作占50%以上，調(diào)整jedispool的設置，基本上屏蔽了ping的操作

8.bolt端batch處理，減少寫入量

9.40%的expire操作，測試ttl+expire vs expire的性能，基于ttl+expire的方式在一個操作里面的性能損耗在35%左右，

如果是同一個key在一個線程里面順序操作會有性能的提升（目前我們沒有這種場景）

1)直接expire

hardedJedis.set(key,value)

hardedJedis.expire(key,1000)

2)ttl+expire

hardedJedis.set(key,value)

Long re = shardedJedis.ttl(key);

if ((re == -1)||(re == -2)){hardedJedis.expire(key,1000)};

10.從第8點測試來看40%的expire操作是省不了了，只能從提高單次處理量(pipline)來做優(yōu)化了

11.測試了lvs->twemproxy->redis的方案，不太穩(wěn)定，考慮引用到的組件比較多，twemproxy相對來說對于我們這邊也是一個黑盒

12.jedissharding的方案在高峰時會有一些延遲，單機方案相對來說比較穩(wěn)定，如果接入數(shù)據(jù)量變大的話還是要走sharding模式，延遲的原因需要繼續(xù)跟進

最后附幾個監(jiān)控圖：

1.redis cpu

2.redis conns

3.redis command/s