基本概念

延时队列的难点不在“等一段时间”，而在“到时间后尽量准时、只执行有效任务、失败后还能恢复”。在进入具体技术方案前，本章先把延时任务的基础概念讲清楚，避免后面把不同问题混在一起。

本章会围绕三个核心问题展开：任务什么时候算到期，任务以什么模型存储和流转，以及系统如何定义可靠性。订单超时取消、优惠券失效、自动确认收货这些场景看起来相似，但它们对准时性、幂等性、取消能力和补偿能力的要求并不完全一样。

延迟语义需要区分“固定延迟”和“指定时间”。前者是从任务创建开始计算，例如 30 分钟后取消订单；后者是某个绝对时间点触发，例如凌晨 2 点结算。系统还要决定允许多少误差：秒级延迟可以用轮询或 ZSet 承担，毫秒级调度则需要更严格的内存结构和调度线程。

队列模型会决定后续架构。一个任务至少需要任务 ID、业务类型、执行时间、状态、载荷、重试次数和幂等键。任务从 pending 到 ready，再到 running、success 或 failed，每个状态转换都应可追踪。没有状态模型，延时队列很容易变成一堆无法解释的定时脚本。

可靠性则要求系统面对故障时仍然可恢复。调度器宕机不能丢任务，执行器超时不能无限重复扣库存，任务失败要能重试或进入死信队列，业务侧要通过幂等键保护最终效果。学完本章后，你会用统一语言描述延时任务，而不是直接跳到某个中间件用法。