如何在指定日期节点到达时保证事件仅触发一次

这类定时触发场景是企业级业务里的通用需求，不需要自研复杂逻辑，用「状态机+抢占式更新+分层兜底」的成熟模式即可完全覆盖你提到的重复触发、漏触发问题，不需要承担复杂架构的维护成本。

核心问题针对性解法 #

重复触发问题根治方案 #

不要使用NOW() + 10 days > scheduled_date这类无状态的判断逻辑，从数据模型层面加状态锁做抢占：

• 首先给存储演出计划的数据库表新增两个布尔类型字段：pre_triggered（默认值0，标记计划前10天事件是否已触发）、post_triggered（默认值0，标记计划后3天事件是否已触发）
• 定时任务拉取待处理记录时，直接把未触发作为核心过滤条件，示例SQL：

-- 拉取满足前10天触发条件的待处理记录
SELECT id, scheduled_date, ext_info FROM show_plan
WHERE pre_triggered = 0
  AND scheduled_date <= DATE_ADD(NOW(), INTERVAL 10 DAY)
LIMIT 1000;

• 拉取到记录后，不要先执行业务事件逻辑再更新状态，必须先通过乐观锁抢占执行权：针对单条记录执行更新语句UPDATE show_plan SET pre_triggered = 1 WHERE id = ? AND pre_triggered = 0，只有当更新返回的影响行数为1时，才执行后续的事件推送、业务逻辑处理；如果影响行数为0，说明这条记录已经被其他任务实例抢占触发，直接跳过即可。

这个机制把无状态的时间对比变成了有状态的资源抢占，哪怕多台任务节点同时拉取到同一条记录，也只会有一个节点拿到执行权限，从根源上避免重复触发。

漏触发问题根治方案 #

不要把查询窗口和定时任务执行周期绑定做窄区间查询，用宽窗口查询+多层兜底的逻辑：

• 常规定时任务设置为每分钟执行一次即可，查询时不对时间范围做上下限硬截断，只筛选「满足触发时间条件、且触发状态为未触发」的记录。哪怕某一分钟任务因为服务重启、数据库抖动、网络故障执行失败，下一分钟任务启动时，会自动把之前漏处理的符合条件的记录拉取处理，不会出现时间窗口错位导致的遗漏。
• 额外增加一个每日低峰期（比如凌晨2点）执行的全量校验兜底任务，扫描所有触发状态为未触发、且已经过了对应触发时间点的记录，重新执行触发逻辑，覆盖极端异常场景（比如之前触发时业务链路全挂、状态更新失败的情况）。

大规模场景增强方案 #

如果你的演出计划量级达到十万、百万级别，直接轮询数据库会有不必要的性能开销，可以选择以下两类成熟方案优化：

• 分布式任务调度分片方案：使用成熟的分布式任务调度框架做分片调度，将所有计划ID按哈希规则拆分到不同任务节点执行，避免单节点拉取全量数据的压力，框架自带的失败重试、分片一致性能力可以减少自研分布式竞争逻辑的成本。
• 延时消息预投递方案：在新建演出计划时，直接计算两个触发时间点，向消息队列投递对应延时值的延时消息（前10天事件的延时值为「计划时间减10天减当前时间」，后3天事件的延时值为「计划时间加3天减当前时间」），消息到期后由消费者直接执行对应事件逻辑。该方案不需要轮询数据库，性能最高，但依然需要保留前面提到的每日全量校验任务，兜底消息丢失、消费失败的异常场景。

通用注意事项：所有事件的业务执行逻辑必须做幂等校验，可以给每个事件生成全局唯一的业务标识（规则为计划ID_事件类型，比如1001_pre代表1001号演出的前置提醒事件），执行前先校验该标识对应的事件是否已经处理完成，哪怕上层状态锁出现极端异常，也不会出现重复执行业务逻辑的问题。

内容的提问来源于stack exchange，提问作者Trent