延迟队列要解决的核心问题只有一个：让任务在指定时间点被触发。普通队列的FIFO特性天然做不到这件事，所以需要引入时间维度的排序能力。电商下单30分钟未支付自动关单、IM消息2分钟内可撤回，这类需求都依赖精准的定时触发。
三种主流方案，先想清楚再选
数据库轮询最直观：定时扫表，比对执行时间字段。问题是无效查询量随数据增长线性膨胀，表一大就拖垮DB。
Redis ZSET是折中方案：score存时间戳，ZRANGEBYSCORE拉取到期任务。依赖Redis可用性，但工程上足够成熟。
RabbitMQ的x-delayed-message插件提供原生延迟能力，代价是插件本身的可靠性和运维复杂度需要额外评估。
这里选的是自建内存队列加持久化兜底的路子。用Go的container/heap实现最小堆，按执行时间排序。好处很直接：不依赖外部中间件，内存操作延迟极低。
核心数据结构与调度循环
任务结构体只保留两个字段：执行时间和处理函数。队列本身持有一个最小堆和一把互斥锁。
Push操作加锁后直接heap.Push，逻辑简单。Start方法启动独立goroutine做轮询检测：堆顶任务的执行时间已到，就Pop出来异步执行Handler。
这里有个坑：轮询间隔设成10ms，空队列时Sleep 100ms。如果业务对延迟极度敏感，这个精度可能不够；反过来如果任务量稀疏，10ms的轮询纯属浪费CPU。实际部署时建议把间隔做成可配置参数。
另一个容易忽略的点：heap.Pop之后才go task.Handler()，如果Handler panic，整个调度goroutine不会挂，但那个任务就静默丢了。生产环境务必在Handler外层包recover，并接入告警。
持久化与分桶：别等进程挂了才后悔
纯内存队列最大的风险是进程异常终止后任务全丢。定期把队列快照写入Redis或磁盘是必要的兜底手段。快照频率取决于业务能容忍多少数据丢失，没有统一答案。
任务量上去之后，单队列的锁竞争会成为瓶颈。分桶策略把任务按时间范围切到多个子队列，各自独立加锁，能显著降低争抢。
任务量超过10万级时，最小堆的O(log n)插入和弹出开始显现压力，可以考虑时间轮算法。时间轮在定时任务密集的场景下检索效率更高，但实现复杂度也上一个台阶。
监控方面，至少采集四个指标：队列长度、任务处理延迟、错误次数、快照写入耗时。队列长度持续上涨通常意味着消费能力不足或Handler阻塞。
性能参考与适用边界
在4核8G机器上的基准测试结果：写入吞吐约12万任务/秒，时间精度误差小于5ms，每个任务内存占用约128字节。
这些数字只在特定硬件和任务结构下成立，换环境需要重新压测。
适用场景：单机任务量在十万级以内、对中间件依赖有严格限制、延迟精度要求毫秒级。
不适用场景：需要跨节点分布式调度、任务量持续百万级以上、要求强一致持久化。这些情况建议直接上Kafka或RocketMQ的延迟消息能力，自建方案的运维成本划不来。
延伸场景与选型建议
金融交易的止盈止损触发、物流超时自动确认收货、在线考试倒计时强制交卷，都可以套用这套模型。缓存LRU淘汰策略的增强也可以用延迟队列做异步清理。
Go的并发模型和内存管理确实适合写这类组件。但选型时先问自己三个问题：任务量多大、能接受多长的停机恢复时间、团队有没有精力维护自建方案。答案清楚了，方案自然就定了。
