Draft: 考虑是否可以更加细颗粒的控制延迟队列,支持一定的积压量

[wppurking]

业务场景会遇到有 rate limit 的 api 调用, 当然可以直接交给外部的 rate limit 去处理. 但这样在与 mq 之间沟通的时候, 会浪费大量的计算资源在做重复的事情. 可以将任务分成两种进行考虑:

1. one shot 类型: 正常让 mq 进行主动推送到 client, 然后进行执行处理既可以. 这里的要求是拥有一定的任务堆积能力, 以及消息处理速度的快慢. 能够方便的根据情况进行 consumer 的增加减少, 能够堆叠 1000w 以内的消息量(再多, 就应该是任务消费的问题了)
2. delay 类型: 这类现在是简化的利用 mq 的 dlx 进行 retry 重试, 但因为是 push 模型, 所以无法进行主动的任务量获取的控制. 如果需要更加精确的 delay 或者 schedule 类型的任务, 则需要利用新的数据结构或者中间件来解决这个问题.

[kenyonduan]

在 spapi 中还有另外一个场景，就是单个任务的 delay 的计算是依赖于 sptoken 的同类型的任务数量的。

比如我有三个订单都需要获取订单项，而三个消息不在同一个 context 中，这样在 publish 消息的时候是无法计算出 delay 的，只能依赖于 redis 中间件提供的队列来提供主动式的 trigger，这样才能满足要求。

[wppurking]

提供两种实现:

1. 直接使用内存中的 SortedSet 来实现.
2. 使用 redis 的 zset 来实现

内存中实现是考虑, 单实例性能足够的时候, 如果可以内存中解决就不需要额外引入依赖, 也不需要依赖 redis 中间件. 并且这个暂存的任务, 也只有在运行时存在, 提供最小的依赖保持最简单的使用.

提供外部的 redis 实例的支持, 主要是额外增加两个能力, 多 huthc-java 实例的支持以及任务的持久化的支持, 如果实在有需要, 再添加 redis 的参数.

[wppurking]

https://github.com/mperham/sidekiq/wiki/Ent-Rate-Limiting

sidekiq 的这个方案很棒