storm寫redis問題小結

  最近一直在跟進storm的問題，從storm集羣的穩定性到監控到升級到bolt寫redis的問題,由於公司目前沒有專業運維redis的，只能咱們數據部門本身搞了。。下面記錄下遇到的幾個問題:

總結下目前storm寫redis問題:

1.redis高峯寫入異常，增長redis監控，發現cpu性能瓶頸(redis單線程，最高10w/s的處理量)

2.以前redis bolt的併發在200以上，過多的併發對redis的性能形成比較大的影響，如今已經減小爲5

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

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

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

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

7.對高峯時的數據進行分析，40w/s的處理量中，ping操做佔50%以上，調整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)來作優化了

11.測試了lvs->twemproxy->redis的方案，不太穩定，考慮引用到的組件比較多，twemproxy相對來講對於咱們這邊也是一個黑盒

12.jedissharding的方案在高峯時會有一些延遲，單機方案相對來講比較穩定，若是接入數據量變大的話仍是要走sharding模式，延遲的緣由須要繼續跟進

最後附幾個監控圖：

1.redis cpu

2.redis conns

3.redis command/s