限流，通常讲就是限制流量，也有很多其他的说法，比如：限频、疲劳度控制等。

最近遇到一个需求，系统A作为一个专门推送消息给客户的消息中心系统，对于每个客户是否能接受消息，能接受多少消息，接收消息的速度，能接受哪些消息等都要进行控制，这也就引入了需要做消息限流的需求了，而且是多维度的。

分析

对于限流的维度来讲，上面提到需求中可以提炼出有：客户维度，消息类型维度；从限流的本身来讲，有频率控制，数量控制。详细说一下：

  • 客户维度：客户的适当性，该客户是否可以接受消息（客户状态）；
  • 消息类型：订单类消息和推广类消息不一致，订单类要及时一些，推广类不及时也行；
  • 消息频率：消息的频率有快有慢（动态时间窗）；
  • 数量控制：固定时间段内能接收的消息数量（固定时间窗），不同客户能接受消息的数量等等。。。

通过以上分析可得每个能成为影响客户接受消息的频率因素，在将这几个维度组合起来，频率控制的组合，策略，就有很多了。
市面上的限流组件有很多，我之前用过的就是Sentinel，该框架只需要对需要做限流的接口做一些简单的配置，加几个注解（埋点），即可通过Sentinel自身的限流规则加上接口的一些参数做到限流。不过，对于非技术人员来讲就不太友好，对此，还是自己设计一个限流的组件，或者模块比较合适，后续的文章会对该需求慢慢实现。

目前大致的想法就是从不同维度分析，设计客户，消息类型，限流记录等几个表，用来记录限流的策略；通过Redis实时记录、更新发送消息的频率数据… … … … …