自定義開發限流元件 之 場景需求分析

限流，通常講就是限制流量，也有很多其他的說法，比如：限頻、疲勞度控制等。

原文連結：自定義開發限流元件 之 場景需求分析-一隻小Coder

最近遇到一個需求，系統A作為一個專門推送消息給客戶的消息中心系統，對于每個客戶是否能接受消息，能接受多少消息，接收消息的速度，能接受哪些消息等都要進行控制，這也就引入了需要做消息限流的需求了，而且是多元度的。

分析

對于限流的次元來講，上面提到需求中可以提煉出有：客戶次元，消息類型次元；從限流的本身來講，有頻率控制，數量控制。詳細說一下：

• 客戶次元：客戶的适當性，該客戶是否可以接受消息（客戶狀态）；
• 消息類型：訂單類消息和推廣類消息不一緻，訂單類要及時一些，推廣類不及時也行；
• 消息頻率：消息的頻率有快有慢（動态時間窗）；
• 數量控制：固定時間段内能接收的消息數量（固定時間窗），不同客戶能接受消息的數量等等。。。

通過以上分析可得每個能成為影響客戶接受消息的頻率因素，在将這幾個次元組合起來，頻率控制的組合，政策，就有很多了。

市面上的限流元件有很多，我之前用過的就是Sentinel，該架構隻需要對需要做限流的接口做一些簡單的配置，加幾個注解（埋點），即可通過Sentinel自身的限流規則加上接口的一些參數做到限流。不過，對于非技術人員來講就不太友好，對此，還是自己設計一個限流的元件，或者子產品比較合适，後續的文章會對該需求慢慢實作。

目前大緻的想法就是從不同次元分析，設計客戶，消息類型，限流記錄等幾個表，用來記錄限流的政策；通過Redis實時記錄、更新發送消息的頻率資料… … … … …