限流，通常講就是限制流量，也有很多其他的說法，比如：限頻、疲勞度控制等。 原文鏈接：自定義開發限流組件 之 場景需求分析-一隻小Coder 最近遇到一個需求，系統A作為一個專門推送消息給客戶的消息中心系統，對於每個客戶是否能接受消息，能接受多少消息，接收消息的速度，能接受哪些消息等都要進行控制，這也 ...
限流，通常講就是限制流量，也有很多其他的說法，比如：限頻、疲勞度控制等。
原文鏈接：自定義開發限流組件 之 場景需求分析-一隻小Coder
最近遇到一個需求，系統A作為一個專門推送消息給客戶的消息中心系統，對於每個客戶是否能接受消息，能接受多少消息，接收消息的速度，能接受哪些消息等都要進行控制，這也就引入了需要做消息限流的需求了，而且是多維度的。
分析
對於限流的維度來講，上面提到需求中可以提煉出有：客戶維度，消息類型維度；從限流的本身來講，有頻率控制，數量控制。詳細說一下：
- 客戶維度：客戶的適當性，該客戶是否可以接受消息（客戶狀態）；
- 消息類型：訂單類消息和推廣類消息不一致，訂單類要及時一些，推廣類不及時也行；
- 消息頻率：消息的頻率有快有慢（動態時間窗）；
- 數量控制：固定時間段內能接收的消息數量（固定時間窗），不同客戶能接受消息的數量等等。。。
通過以上分析可得每個能成為影響客戶接受消息的頻率因素，在將這幾個維度組合起來，頻率控制的組合，策略，就有很多了。
市面上的限流組件有很多，我之前用過的就是Sentinel，該框架只需要對需要做限流的介面做一些簡單的配置，加幾個註解（埋點），即可通過Sentinel自身的限流規則加上介面的一些參數做到限流。不過，對於非技術人員來講就不太友好，對此，還是自己設計一個限流的組件，或者模塊比較合適，後續的文章會對該需求慢慢實現。
目前大致的想法就是從不同維度分析，設計客戶，消息類型，限流記錄等幾個表，用來記錄限流的策略；通過Redis實時記錄、更新發送消息的頻率數據... ... ... ... ...
