電商平臺常常舉行一些秒殺場景的活動來對商品進行促銷,來帶動整個企業的影響力;而秒殺活動通常是在特定的時間、特定的商品進行限量的銷售搶購,這樣會吸引大量的用戶進行搶購,並在活動約定的時間點同時的進行秒殺搶購;這樣也就造成以下特色:html
1)大量用戶同一時間同時進行搶購,網站瞬時訪問流量激增。前端
2)訪問請求數量遠遠大於庫存數量,只有少部分用戶可以秒殺成功。nginx
3)購物車直接下單減庫存。golang
4)秒殺商品下單減庫存。redis
從上面的背景中咱們須要面對的問題就是,針對於電商平臺如何讓它能夠在這種高併發、大流量的請求下讓其可以平穩、滿負荷的運轉。因此這就須要引入流量監控平臺,它可以實時瞭解各個服務器的運做參數、各個業務單元的請求數量;隨時爲決策者提供清晰的數據參考,以備調度。算法
流量監控,又能夠理解爲一種流量整形,是一個計算機網絡的網絡交通管理技術,從而延緩部分或全部數據包,使之符合人們所需的網絡交通規則,速率限制的其中一種主要形式。shell
網絡流量控制是用來優化或保證性能,改善延遲,和/或增長某些類型的數據包延遲知足某些條件下的可用帶寬。若是某一個環節趨於飽和點,網絡延遲可能大幅上升。所以,網絡流量控制能夠利用以防止這種狀況發生,並保持延遲性檢查。數據庫
網絡流量控制提供了一種手段來控制在指定時間內(帶寬限制),被髮送到網絡中的數據量,或者是最大速率的數據流量發送。這種控制能夠實現的途徑有不少,可是一般狀況下,網絡流量控制老是利用拖延發包來實現的,通常應用在網絡邊緣,以控制進入網絡的流量,但也可直接應用於數據源(例如,計算機或網卡),或是網絡中的一個元素。api
限流算法主要爲:漏桶、令牌桶、計數器緩存
一個固定容量的漏桶,按照常量固定速率流出水滴。
令牌桶算法是一個存放固定容量令牌的桶,按照固定速率往桶裏添加令牌。
有時候咱們還使用計數器來進行限流,主要用來限制總併發數,好比數據庫鏈接池、線程池、秒殺的併發數;只要全局總請求數或者必定時間段的總請求數設定的閥值則進行限流,是簡單粗暴的總數量限流,而不是平均速率限流。
如下針對於國內比較大型的互聯網企業針對於流量監控架構方面的信息蒐集
沒有找到相關的技術資料,只是找到2016年分享的 「阿里管控系統靠什麼扛住全球最大規模的流量洪峯?」的文章,文章中提到了其不一樣場景採用的算法和限流框架。
用戶洪峯
考慮的因素是:
a) 容許訪問的速率
b) 系統承受的最大洪峯
c) 洪峯爆發的間隔時間
處理方式: 令牌桶限流
回調洪峯
除了0點0分的這種流量洪峯,還有系統之間的回調引發的洪峯。想象一下這樣的場景,物流系統爲了處理髮貨信息,會隔一段時間調用交易系統來獲取交易信息。爲了提升效率,它每次批量查詢交易系統的數據。這樣,對交易系統也帶來了流量的衝擊。若是對這種回調不加以限制,那麼可能交易系統忙於處理這種回調洪峯,對用戶洪峯會疏於處理。
對於這種洪峯,有三種特點:
a) 有間隔頻率
b) 每次調用量大
c) 容許有延遲
處理方式:漏桶算法
限流框架分爲:監控模塊、決策模塊、規則變動模塊、限流模塊。
騰訊採用一種輕量級流控方案,方案以下:
一、計數器的key能「計時「
首先選擇使用ckv做爲計數器存儲,相比redis開發會更熟悉,同時維護也更容易,固然該方案也能夠選擇redis做爲計數器存儲。
優點:方案用簡單的方式將全局流控服務作成原子化(計數和計時原子化),開發門檻低。
二、請求統計用拉取的方式替換上報
對於請求的統計方式,通常全量上報不可行,全部業務的請求量至少1:1上報到ckv,ckv的容量和是個問題,單key也容易成爲熱點。定時或者定量批量上報,都沒法保證明時流控,特別是請求量大的時候,流控延遲的問題會被放大。
優點:方案減小ckv的訪問量,同時保證流控的準確性。
三、部署不須要agent
爲了作更輕量的方案,咱們考慮agent的必要性,分析發現,agent要完成的功能比較簡單,主要功能託管到業務流控api。
優點:方案不採用agent的方式,部署維護更簡單。
四、全局及單機流控同時啓用
方案對容災作了充分的考慮,主要解決方式是全局及單機流控同時啓用,即基於ckv的全局流控和基於單機共享內存的單機流控都同時工做。
優點:方案有很好的容災能力,容災方式簡單有效。
五、解決ckv性能瓶頸,流控性能達百萬/s
因爲使用ckv的incr以及配額拉取的實現方式,全局流控接入服務請求的能力獲得成本增加。
目前方案單獨申請了一塊ckv,容量爲6G,使用incr的方式,壓測性能達到9w+/s。
對業務空接口(Appplatform框架)作流控壓測,使用30臺v6虛擬機,單機50進程,壓測性能達到50w+/s。
單接口50w/s的請求的服務接入,一樣也能知足多接口整體服務請求量50w+/s的全局流控需求。
上述的壓測瓶頸主要是Appplatform框架的性能緣由,因爲拉取配額值是根據流控閾值設定(通常>10),50w+的請求量只有不到5w的ckv訪問量,ckv沒到瓶頸。
優點:方案使用同等的資源(單獨一塊6G的ckv),能知足業務的請求量更高,性能達百萬/s。
六、支持擴容和動態流控升級
支持平行擴展流控能力,一套全局流控部署能知足流控的服務請求量是達百萬/s,更大的服務請求量須要部署多套全局流控。
支持升級到動態流控能力,ckv寫入的流控閾值是經過定時管理器完成,目前業務已經作了健康度上報,定時管理器只須要對接健康度數據,分析接口當前請求狀況,動態調整流控閾值便可達到動態流控能力。
優點:方案總體簡單輕量,擴容和升級都很容易。
關鍵流程圖
京東10億調用量的高可用網關係統所涉及的技術棧:
接入層 Nginx+lua 技術。
NIO+Serviet3 異步技術。
分離技術。
降級限流。
熔斷技術。
緩存,哪些地方該加緩存,哪些地方能夠直接讀庫。
異構數據。
快速失敗。
監控統計,這是整個高可用網關係統裏很是重要的一部分。
小米搶購限流峯值系統針對於小米商城秒殺搶購的實現及技術架構
大秒系統的架構設計
大秒系統主要由以下幾個模塊構成
限流集羣 HTTP 服務放號策略集羣 Middle 服務監控數據中心 Dcacenter監控管理體系 Master準實時防刷模塊 antiblack基礎存儲與日誌隊列服務: Redis 集羣、Kafka 集羣等
整個大秒體系中大秒前端模塊 (HTTP/middle/antiblack) 和監控數據中心使用 golang 開發,大秒監控管理體系使用 Python + golang 開發。
大秒的前端架構設計
大秒前端的架構設計從三個系統展開
限流集羣 HTTP 服務
策略集羣 Middle 服務
準實時反做弊 antiblack 服務
基於SOA架構理念,下降系統耦合性,接口定義清晰明確,保證獨立子系統的健壯性高,下降故障跨系統擴散風險,從而將伸縮性的困難逐步分解到各個系統。
對系統進行分級,集中力量,突出重點系統。噹噹網從賣場到交易流程均屬於一級系統,這部分系統直接關乎用戶體驗和訂單量。在系統穩定性和可靠性等指標上,設計標準高於後臺系統。
優先考慮用異步處理代替同步處理,作好系統異常的降級方案,保證有限的合格服務。
經過資料的收集,參考各大互聯網企業的流量監控平臺的架構搭建方案,大概瞭解涉及的系統模塊組成、限流算法、限流方式和原理。
綜合各方資料整理得出簡要的流量監控方案,流量監控能夠分爲多個系統組成來完成其職責,這個平臺主要的組成部分是:流量上報、限流、策略、調度。
主要用於採集系統的請求數據、狀態和系統運行情況。有了這些運行數據,才能對外或對內進行決策處理;
1)對外和對外
對外用戶請求
對內各個系統之間的回調請求
2)上報數據格式標準化
上報數據制定標準的
3)數據質量
4)實時和延時上報
5)硬件監控,如服務器的CPU、內存、網卡
6)心跳監控,時刻了解每個機器的運行狀態
7)業務層監控,涉及JVM,Nginx的鏈接數
1)、採用開源與shell腳本搭建監控平臺
2)、自行研發監控平臺
主要是根據流量上報的數據結合策略、調度來 進行對超出預期請求的處理方式,好比限流、排隊等措施;
根據不一樣場景採用不一樣的限流算法,能夠借鑑阿里針對於用戶訪問、物流、交易的處理方式。
1)用戶訪問:採用令牌桶方式;
2)物流、交易:採用漏桶方式,平滑削峯處理;
3)購物車:採用分塊網格化,單元處理
主要是經過提早設置的系統、業務場景參數,來用於決定什麼場景用什麼限流方式;相對的風險的應對,也是策略的重要之處;在活動進行時,根據監控上報的流量數據,動態靈活的調整策略也是很是重要的;經過整理的資料提成一下策略方案:
1)水平擴展
針對不一樣服務器的壓力進行增減服務器個數以實現服務的壓力負載均衡,這樣的話對於系統剛剛開始的伸縮性設計要求比較高,可以很是靈活的添加機器,來應對流量的變化。
2)系統分組
系統服務的業務不一樣,有優先級高的,有優先級低的,那就讓不一樣的業務調用提早分組好的機器,這樣的話在關鍵時刻,能夠保核心業務。
3)業務降級
在一個用戶請求,涉及到多個邏輯處理,其中有的是能夠沒有的,能夠在高併發的狀況下,能夠經過開關設置,來對非主要邏輯出來進行關閉其請求,以提高了系統的主業務能力。
4)開關設置
對於每個系統業務請求,都增減相應的開關設置,能夠實時應對高併發狀況下,根據場景實現動態調度的做用。
提供給決策者相應的調度數據,實時展示系統運行狀態,並在決策者下達決策指令後迅速執行策略;如何來實現大概的方案以下:
一、創建中心數據可視化平臺
二、策略規則能夠動態配置
三、各個業務線開關集中管理
四、自動化的腳本執行
五、運維服務的動態化管理
六、命令執行的分發協議和協同管理
流量監控爲電商平臺提供高效穩定的運行環境的基石,它是無時不刻的監控整個平臺的運行狀態、併爲決策者提供實時數據以供參考;流量監控平臺中的限流只是一種保護機制,如何承載高併發、大流量的用戶請求,仍是須要與其餘平臺協做,以達到給用戶極致的用戶體驗。
騰訊輕量級全局流控方案詳解
噹噹網系統分級與海量信息動態發佈實踐
http://www.csdn.net/article/2014-11-07/2822541
https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=402182304&idx=1&sn=1bd68d72e6676ff782e92b0df8b07d35&scene=1&srcid=12045k1zDgO7DLlMLwimBKjC&from=groupmessage&isappinstalled=0#wechat_redirect