1. @
niubee1 #46 @
yangyuhan12138 #48，楼主，你在 48L 提的“我们需要有个异步去还原未支付的库存” 与 46L 说的加一个过期字段并不冲突。举个例子，每分钟跑一次，将过期的订单 select 出来，逐个处理。
2. 说下我的想法
- 2.1 轮询(定时)：最简单做就是加一个字段，每隔一段时间轮询一次数据库，逐个处理（弊端：符合条件的订单数太多，处理比较慢）
- 2.2 用延时队列：直接放到队列里，多个消费者并行处理（弊端：订单数太多，mq 积压）
- 2.3 轮询 + 延时队列：就是 39L 提到的。不多余好吗，楼主你不是担心消息数太多，MQ 内存顶不住吗。这个方案就是把即将过期的提前一点入队列，解决了 2.2 和 2.3 的弊端
以上三种方法都没毛病，按实际需求选择。个人建议不要过度设计，怎么简单怎么来，提前优化就提前提高了系统复杂度。如果是我选择，就用 2.2 。
针对楼主的主题内容再聊聊我的一些看法：
3. rmq 的水平扩容？多加机器节点不就是水平扩容吗。楼主提到现在 3 个节点，且队列都设置为镜像模式。看样子架构师很没有安全感呢。一般来说一主一从就可以了，即镜像数量设置为 1 个节点，我认为是 ok 的。这样，随着节点的数的增加，就分摊到不同节点了。因此，楼主提到的“上限还是为单台机器的容量”这个麻烦，实则是自己给自己找的。
4. redis zset 方案。这个方案实则是自己实现了一套不怎么靠谱的延时队列，有现成的 delayQueue 不用，折腾这个是干啥？是有别的考虑吗。
5. RMQ 的延时队列，可以用插件实现，不需要自己用死信队列实现了。