数据库轮询方案

数据库轮询是最容易上线的延时队列方案：把任务写入一张表，定时扫描 execute_at <= now() 且状态为待执行的记录，然后批量取出执行。它不优雅，但非常适合作为课程里的第一版，因为它能把任务状态、索引、批处理和故障恢复问题暴露得足够清楚。

本章会先设计一张延时任务表：任务 ID、业务类型、执行时间、状态、重试次数、锁定时间、载荷和幂等键。然后用一个调度器按固定间隔扫描到期任务，并通过状态更新把任务从待执行转为执行中。这个过程看似简单，但每一步都关系到是否会重复执行或漏执行。

数据库方案的关键是索引和批量处理。最常见的查询条件是状态加执行时间，因此需要围绕 (status, execute_at) 建索引；任务量上升后，还要按业务类型或分片键拆分扫描范围，避免单表热点。批量拉取任务时不能一次拿太多，否则会拖慢事务，也不能太少，否则调度延迟会抖动。

本章也会讨论它的边界：轮询间隔决定最小调度延迟，数据库承受扫描压力，多个调度器需要抢占机制，任务执行失败需要重试和释放锁。对于中小规模业务，数据库轮询可以稳定工作；对于百万级高频任务，它通常会成为调度性能和数据库成本的瓶颈。

完成本章后，你应当能做出一个可用但有边界的第一版延时队列，并能清楚说明它什么时候够用、什么时候必须演进到 Redis、消息队列或时间轮。