【轉】大資料分析中Redis怎麼做到220萬ops

發表於2018-01-22

原文:http://www.cnblogs.com/nnhy/archive/2018/01/16/Redis220.html

 

大資料時代,海量資料分析就像吃飯一樣,成為了我們每天的工作。為了更好的為公司提供運營決策,各種抖機靈甚至異想天開的想法都會緊跟著接踵而來!業務多變,決定了必須每天修改系統,重新跑資料,這就要求極高的海量資料讀取和儲存速度!

公司每天增加幾億行的業務日誌資料,我們需要從中分析出各種維度的業務畫像。經過很長時間的摸索,選擇了Redis作為讀寫資料的快取。

 

1,開發平臺,C#Net,寫Windows服務抓取原始日誌資料,合併精簡壓縮後,寫入Redis叢集。

2,各業務系統從時間維度上遍歷Redis快取資料,逐行分析處理,中間結果和最終結果寫入Redis。

3,另一套Windows服務抓取Redis裡的結果資料,儲存回資料庫。這裡有點像MQ的工作方式。

實際上,第一步只有一套系統,這是資料基礎。第二第三一般每個子系統都有一對。甚至A系統的結果直接訪問B系統放在Redis中的結果資料。

整體上看起來耦合度有點高,但是這一套架構得到了極高的速度,單個子系統例項每秒鐘可處理1萬到10萬個訂單!並且是很多套子系統同時工作,單一子系統因業務原因不會吃完全部Redis效能。單獨對某一臺Redis伺服器做壓力測試,最高得到了222萬ops的速度,測試的是比較簡單的業務,統計滿足某種業務規則的訂單總數。

 

為何需要這麼高速度??

業務規則一旦改變,修改程式後,往往需要重新跑最近一週什麼一個月的歷史資料。如果每天改幾次呢?如果趕上雙十一旺季,太慢的速度恐怕連實時資料都趕不上。

 

Redis怎麼做到220萬ops

1,Redis是單執行緒模型,因此32核心伺服器安裝32個例項

2,資料分片,key雜湊後均分到幾十個例項上

3,關閉持久化,運維和Linux保證可靠性

4,控制好資料包大小,高效能網路通訊最忌收發大量小包,控制在1400位元組附近最佳,最差也要pipeline

5,其它在網上能輕易找到的細小技巧

 

為什麼不用資料庫??

經過大量驗證,同樣32核心伺服器,資料庫3巨頭一般得到20000qps的查詢速度和接近10000tps的寫入速度。這是按照單表幾百萬資料有兩個索引的情況測試。如果資料達到幾千萬上億,再多兩個索引,讀寫同時進行,那麼速度只剩下四分之一不到。真真一個慘字!

大資料分析,有很多是臨時資料,需要合併、疊加、去重等等,它們的生命週期不長,一般24小時或48小時,也有不少是兩三個小時,關鍵是資料量還特別大,每天幾千萬很常見。這類資料,寫資料庫是很不合適的。

而使用Redis,一臺32U512G機器,可以裝下一個月幾十億經過壓縮處理的歷史資料,資源佔用在50%上下。

 

我是大石頭,打1999年起,18年老碼農。目前在物流行業從事資料分析架構工作。歡迎大家一起C#大資料

我不相信神話,我只相信汗水!我不相信命運,我只相信雙手!
 

相關文章