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

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

總結下目前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

文章標題：storm寫redis問題小結
當前URL：http://vcdvsql.cn/article30/jhgjso.html

成都網站建設公司_創新互聯，為您提供品牌網站建設、靜態網站、網站導航、動態網站、商城網站、虛擬主機

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯