【寻求建议】用EMQX钩子开发一个主题级限制插件

问题描述

在实际的业务需求中,我需要限制每个主题每日的消息发送数量并进行记录。
例如,设置消息发送数量为5000,首先记录每个主题的消息发送数量,超过5000后进行限制发送。

目前想法如下:
存储为Redis集群,通过编写钩子,在 message.acked 挂载点执行,将key-value->主题-数量写入及更新到redis中,然后每次在 message.publish 挂载点检查该主题已发送的消息数量,若超过5000则丢弃消息。

由于自身只在应用层浅层有开发经验,故有以下疑问:

  • 该方式可行性如何?
  • 在性能上的消耗会很大吗?(本身该需求是为了减轻服务器压力,和不限制消息数量发送相比,若性能消耗反而略大,已属于伪需求)

同时,若各位有更好的意见和建议,希望能给到!

如果是为了减轻服务器压力,需要的是限速,不是限量。
参考文档,速率限制章节,这一部分比较难,需要仔细看。

之前配置过这速率限制,但是实际得到的结果好像是,算法检测到速率过快后限制了消息的发送,但过了一个单位检测时间后,之前限制期间发送的消息没有被丢弃,而是一下子全部发出来了?

限制消息发送不能丢弃消息的,我们从不会主动的丢弃消息,只有消息没有消费者,才会被丢弃。
你可以限制每十秒一条这样的速率,设备就只能按这个速度发出来了。

方便分享一下你的务场景吗?需要在5000条之后丢弃设备消息?我还没有见过这样的使用方式

您好,是这样的,因为是做平台类的项目,所以场景需求是:
为了避免平台下开发者的设备不加延时地循环上报数据,对服务器造成影响,所以需要采用一定的措施对这种行为进行限制,因此想了两个方案:

  • 限制消息发送数量,单天或某单位时间内超过N条则拒绝该设备消息发送(同时也方便后续为超出N条消息量的计费提前做好扩展)
  • 通过速率限制,超过该速率的消息将发送不出去并丢弃

但最终结果还是要从服务器减压方面考虑 :rofl:

目前只有一个办法,钩子统计,然后禁用这个client发送数据,性能会吃力一些。
不过为啥不设计成按量付费呢?上报数据按条目收费呀,目前主流的平台都是这样玩的

还得限制消息格式,避免用户把10条数据压缩成一条