轉自:https://blog.csdn.net/zzaric/article/details/80641786
redis
應用場景以下:服務器
公司內有多個業務系統,因爲業務系統內有向用戶發送消息的服務,因此經過統一消息系統對外暴露微服務接口供外部業務系統調用,全部公司內業務系統的消息(短信,APP,微信)推送都由統一消息系統去推送,短信推送須要走外部短信通道商去發送短信,APP和微信走內部系統的push服務器,可是無論是短信通道商仍是內部push服務器都會有每秒上限的控制。在這假設n/s條。微信
如下是統一消息系統內部的具體的限流方案:微服務
時間限流隊列以下:.net
1.統一消息中心接受消息m條,假定這m個待推送消息的推送時間爲t1。線程
2.由於時間限流隊列的長度是n條,如今有m條要進時間限流隊列,因此隊列裏必需要有n-m個長度才能保證新進來的m條待發送消息才能進入隊列。blog
3.因此斷定隊列裏第n-m對應的時間點要比這m條待發送消息的發送時間小於1個單位秒時,即 t1-t2>1s,才能保證n/s條的速率。接口
4.經過第3部t1-t2>1s?判斷是否知足新來的m條待發送消息的發送時間是否比時間限流隊列第n-m條對應的時間大於1個單位秒時,若是大於1個單位秒時,說明t1時間對應的上一秒對應的n條消息都已經發送,這時經過lpush命令循環將m條待發送消息推入時間限流隊列。若有沒有主線程睡眠1/10個秒時,輪詢執行步驟一,直至m套待發送消息對應的發送時間t1進入至時間限流隊列。隊列
5.執行時間滑動窗口步驟,截取redis隊列0 - n的長度數據,如圖所示。
循環