Redis ZSet 实现延迟队列最省事但需防重复消费，必须用 Lua 脚本原子性完成查删推三步，配合唯一 ID 幂等、合理轮询间隔与持久化；时间轮适合高频短延迟任务；RabbitMQ 插件方案运维成本高且精度有限；强一致场景须 DB 兜底与重试机制。
用 Redis ZSet 实现延迟队列最省事，但得防重复消费
中小型项目直接上 redis.ZAdd + ZRangeByScore 是最快落地的方案，不用额外运维中间件，Go 用 go-redis 几行就能跑起来。
常见错误现象：轮询时只查不删，或先删后处理，导致消息丢失或重复执行；多个消费者同时扫同一个时间窗口，任务被多次取走。
- 必须用 Lua 脚本原子性完成「查 + 删 + 推入待执行队列」三步，否则并发下必出问题
-
Min设为"0"、Max动态传time.Now().Unix()，别硬写死时间戳 - 轮询间隔别太短（比如
100ms），Redis 压力大还容易打满连接；建议500ms~1s，配合ZCount预判是否有活再扫 - 消息体建议带唯一
id字段，消费端做幂等判断，哪怕 Lua 没兜住也有补救
时间轮适合高频定时任务，但别盲目套用分层结构
如果你的系统每秒要调度上千个 1~60 秒内的延迟任务（比如实时风控超时判定），时间轮比轮询 Redis 更稳、更省资源。
性能影响明显：单层时间轮内存占用小，但槽位数一多（比如 6000 个 10ms 槽），current 指针滚动快，goroutine 频繁唤醒；分层轮精度高，但实现复杂、GC 压力大。
立即学习“go语言免费学习笔记（深入）”；
- 优先用单层轮，
interval设为业务容忍的最小延迟粒度（如 500ms），槽位数 = 最大延迟 ÷ interval -
task函数里别做阻塞操作（如 HTTP 调用、DB 写入），应转给 worker pool 异步处理 - 别把
time.Sleep当时间轮——它无法动态增删任务，且 goroutine 泛滥时调度失准 - 重启会丢任务，必须搭配 DB 或日志落盘，恢复时重载未触发任务
RabbitMQ 插件方案看着“原生”，实际运维成本不低
如果你已有 RabbitMQ 集群且团队熟悉 AMQP，启用 rabbitmq_delayed_message_exchange 插件确实能少写逻辑，发消息时加个 delay header 就行。
容易踩的坑：插件不是官方默认内置，不同 RabbitMQ 版本兼容性差；升级集群时可能失效；延迟精度在百毫秒级，不适合亚秒级调度。
- 安装插件后必须重启节点，Docker 环境记得挂载插件目录并指定
enabled_plugins - Exchange 类型必须声明为
"x-delayed-message"，且args中指定"x-delayed-type"（如"direct"） - 延迟值单位是毫秒，不是秒——
header["x-delay"] = "5000"表示 5 秒，写成5就真延迟 5ms - 消息过期后进死信队列？不会。插件是路由时拦截，没到时间根本不投递，不存在 TTL 过期逻辑
别忽略失败重试和持久化，尤其在订单类场景
订单超时取消这种强一致性场景，延迟队列只是触发器，真正关键的是后续状态变更能否成功。一次失败不重试，就可能产生资损。
常见错误现象：任务执行报错后直接丢弃；本地内存队列重启即空；Redis 没开 AOF 或主从同步延迟导致消息“消失”。
- 每个任务结构体里加
retry_count和max_retry字段，失败时递减并重新入队（延迟可指数退避） - Redis 方案务必开启
appendonly yes，RabbitMQ 开启durableExchange/Queue + 消息delivery_mode=2 - 不要把延迟逻辑全压在队列层——比如“30 分钟未支付取消订单”，应在订单表加
expire_at字段，队列只负责提醒，DB 层兜底校验 - 测试时重点压
服务重启、网络分区、消费者宕机三种情况，看任务是否漏掉或重复
延迟队列真正的难点从来不在“怎么发”，而在于“怎么确保它一定被正确执行一次”。时间精度、失败恢复、跨服务一致性，这些地方一旦松动，线上就是静默故障。
