1. 程式人生 > >【轉】大數據分析中Redis怎麽做到220萬ops

【轉】大數據分析中Redis怎麽做到220萬ops

12g 要求 維度 日誌 24小時 線程 物流 line 壓力測試

原文: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#大數據

【轉】大數據分析中Redis怎麽做到220萬ops