記一次高併發、大流量場景下的緩存、限流優化

目錄

場景描述:

歷史優化措施

可行性分析

硬件設備

流量分析

峯值預估【單個服務】

緩存預估

峯值流量處理

可行性方案

源端轉發

分佈式緩存

本地緩存

可行性實踐

案例1

問題分析

基於Guava的本地緩存

基於Guava的令牌桶限流算法

參數配置


場景描述:

平臺接入了大量的圖片,穩定情況下大概1200張/秒;現有架構下內部系統需要先將這部分數據落地並生成結構化URL存儲到分佈式存儲中。同時,需要將已經落地的圖片上傳至三個第三方平臺。目前遇到的問題是推送服務大面積報錯,原因主要是圖片下載失敗,目前的存儲/讀取流程如下:

主要問題表現在,從接入到存儲出現大面積寫入失敗,下載服務也大面積失敗,報錯信息是從存儲集羣獲取連接失敗;

歷史優化措施

之前是做過一些優化,穩定了一段時間,隨着發送的第三發越來越多,最終難以維持。

  1. 針對存儲集羣的連接進行了優化,針對客戶端連接進行了優化

  2. 存儲層面針對讀寫進行了分離

可行性分析

硬件設備

         166個STORAGE +4Tracker   ,之前已經分別針對Storage和Tracker進行了多次優化,Tracker進行了讀寫分離(兩讀兩寫);

         圖片下載服務有8臺;

流量分析

平均單張圖片大小:150 K

平均每條記錄圖片數

  1. 200KB全景圖+4KB號牌特徵圖+110KB車牌特徵圖

  2. 5張

QPS:300/S【每條記錄3-5張圖片,後邊統一爲4】

數據推送方:3

輸入總流量:200M/S

輸出總流量:200*3=600M/S 【估算,應用程序訪問的忽略】

單個下載服務流量=600M /8=75M/S=150張/秒【在增加數據推送可能會以倍數遞增】

峯值預估【單個服務】

         實時場景: 300/S

         積壓1分鐘]:1800/S =74*60=9000張/S

         積壓5分鐘:9000/S=540000張/S        [135000記錄/S]

         消費者限流:1000/S               【限流的閥值是要保證積壓趨向於緩解】

緩存預估

         緩存最近5分鐘的圖片;

         緩存總大小: 150 K*4*300*60*5=5.2G

單個服務緩存大小: 28125/8=6.5G 【加上服務自用內存大體上可以分配8G左右的內存】;

緩存總記錄數:300*4*5*60=360000張

單個服務緩存記錄數:45000

其它粒度依此類推;

峯值流量處理

         上傳服務是分佈式服務,部分場景下允許積壓,極容易出現併發瞬間到達數萬級別. 很容易在啓動時就將下載服務DOWN掉。

         合理的解決方案是進行必要的限流,由於使用了緩存,在緩存預熱期間和緩存預熱後預估的吞吐量差距較大,極端場景下會出現數量級的差異。

         限流需要考慮針對總吞吐量的限流,用來做服務級別的保護;同時要考慮資源級別的保護,對圖片下載來說,可併發的存儲訪問數應該受到保護,避免將峯值流量傳遞到分佈式存儲系統,導致更嚴重的災難。
 

可行性方案

源端轉發

         在圖片數據未落地前直接進行轉發操作;需要將部分邏輯前置;因爲圖片未落地降低了很大一部分由於存儲的IO開銷和網絡延遲;

         【新版的接口可以預留該模塊,需要時允許進行擴展】;

分佈式緩存

         需要一定規模的緩存集羣,分佈式緩存由於跨主機的數據訪問,相比本地緩存效率要低一些;通常對緩存的數據沒有特殊要求,需要結合具體的實現來進行選擇;

         【新版URL設計中去除了與服務主機的強綁定關係,未來可以規劃一個可插拔的緩存接口便於在大流量場景下的快速接入】

本地緩存

         相比之下本地緩存效率更高,分佈式環境下某些資源並不是每次都通過同一個本地節點進行訪問,需要權衡本地緩存與分佈式緩存的適用性;

我們當前的版本中圖片同下載服務存在強綁定關係,基於本地緩存效果更明顯

可行性實踐

案例1

問題分析

         現在表現出以下問題,下面結合以前的問題整理下:

  1. 實時數據接入量在300條/秒,每條記錄3-5張圖片,合計每秒需要存儲1200張左右圖片;每張圖片大小平均在150KB左右;每秒寫入流量在200M左右【穩定情況下】
  2. 實時數據推送,目前一條過車記錄的圖片【字節】,需要給三個第三方推送,輸出輸出總流量大概在500M/秒【穩定情況下】
  3. 曾經多次針對連接進行過優化(連接池、短連接),存儲層面也進行或多次優化,系統現在仍然不穩定,最近一次出問題是由於服務器下電重啓;
  4. 上傳服務與下載服務競爭存儲連接資源,如果下載出現峯值嚴重影響入庫,直接導致入庫操作失敗;

基於Guava的本地緩存

        現有設計中所有圖片路徑中綁定了唯一的圖片下載服務實例,基於此在考慮對整體影響的情況下,在圖片下載服務中使用本地緩存的方式可以大大提高實時圖片讀取的效率。

        

基於Guava的令牌桶限流算法

        

參數配置

        

  1. JVM 配置

                  -Xms4096m -Xmx8000m

  1. 緩存參數配置
#圖片下載緩存優化參數
#最大緩存圖片數
imagedownload.cache.maxSize=15000
#併發訪問數量
imagedownload.cache.concurrencyLevel=8
#初始緩存大小
imagedownload.cache.initSize=500
#緩存過期時間[單位/S]
imagedownload.cache.liveTime=300

#圖片下載限流配置
#接口限流
imagedownload.limit.permitsPerSecondForRequest=2000
#訪問存儲限流
imagedownload.limit.permitsPerSecondForDownload=100

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章