|
我注意到默认最大时长是3天, 我设置为1年(通过broker configuration broker.toml/timerMaxDelaySec=31536000)是否会有巨大的性能或者安全问题 |
Answered by
mxsm
May 16, 2026
Replies: 1 comment 2 replies
|
@l-7-l 低流量、可信生产者场景下不一定会立刻产生巨大问题；高流量或多租户场景下，不建议直接放到 1 年。 主要风险是存储和 IO 放大，不是传统安全漏洞。超过 timerRollWindowSlot 的消息会被周期性 roll。也就是说，1 年后的定时消息不会一次性等 1 年，而是大约每 2 天重新写入一次内部 timer topic，直到接近投递时间。粗略看： 365 days / 2 days ≈ 183 次 roll 安全角度上，它本身不是漏洞，但如果生产者不可信，确实可能变成资源消耗型风险：有人可以大量发送 1 年后的定时消息，占用磁盘、制造长周期 backlog，或者集中到同一个时间点造成 slot 拥塞和到期投递峰值。 建议七天到15天。不要延迟太多， 后续应该会优化这个实现，当前实现是和Java版本一致。 后续会进行优化！现在如果同一时间延迟的很多消息也会有一定的延迟。 |
2 replies
超越 rocketmq 牛逼啊师傅 屌哉 |
大佬优化方向是什么 是将一条消息一个定时器改为跑批么 |
Answer selected by
l-7-l
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@l-7-l 低流量、可信生产者场景下不一定会立刻产生巨大问题；高流量或多租户场景下，不建议直接放到 1 年。 主要风险是存储和 IO 放大，不是传统安全漏洞。超过 timerRollWindowSlot 的消息会被周期性 roll。也就是说，1 年后的定时消息不会一次性等 1 年，而是大约每 2 天重新写入一次内部 timer topic，直到接近投递时间。粗略看：
365 days / 2 days ≈ 183 次 roll
所以每条 1 年定时消息可能带来约 180 多次内部重写，包括 commitlog、consume queue、timer log 等元数据写入。消息量小没什么，消息量大时会明显增加磁盘写入、timer topic 积压、恢复成本和 roll 峰值。
安全角度上，它本身不是漏洞，但如果生产者不可信，确实可能变成资源消耗型风险：有人可以大量发送 1 年后的定时消息，占用磁盘、制造长周期 backlog，或者集中到同一个时间点造成 slot 拥塞和到期投递峰值。
建议七天到15天。不要延迟太多， 后续应该会优化这个实现，当前实现是和Java版本一致。 后续会进行优化！现在如果同一时间延迟的很多消息也会有一定的延迟。