storm寫(xiě)redis問(wèn)題小結(jié)

  最近一直在跟進(jìn)storm的問(wèn)題，從storm集群的穩(wěn)定性到監(jiān)控到升級(jí)到bolt寫(xiě)redis的問(wèn)題,因?yàn)楣灸壳皼](méi)有專(zhuān)業(yè)運(yùn)維redis的，只能我們數(shù)據(jù)部門(mén)自己搞了。。下面記錄下遇到的幾個(gè)問(wèn)題:

總結(jié)下目前storm寫(xiě)redis問(wèn)題:

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

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

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

4.關(guān)閉了redis的rdb持久化方式，開(kāi)啟了aof的方式，在低峰aofrewrite

5.擴(kuò)容到8個(gè)實(shí)例，使用jedissharding的方式，高峰時(shí)單機(jī)超過(guò)5W/s處理量

6.去掉select操作，使用默認(rèn)db0

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

8.bolt端batch處理，減少寫(xiě)入量

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

如果是同一個(gè)key在一個(gè)線程里面順序操作會(huì)有性能的提升（目前我們沒(méi)有這種場(chǎng)景）

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點(diǎn)測(cè)試來(lái)看40%的expire操作是省不了了，只能從提高單次處理量(pipline)來(lái)做優(yōu)化了

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

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

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

1.redis cpu

2.redis conns

3.redis command/s