如何高效检测批量用户订阅到期，避免每日全量加载用户？

关于数据库触发器调用Java代码的可行性 #

不推荐采用这种方式，核心原因如下：

• 数据库与业务逻辑强耦合，后续代码迭代、数据库迁移都会变得异常繁琐；
• 触发器的错误捕获、日志排查难度极高，一旦出现问题很难快速定位根源；
• 数据库资源本就有限，频繁触发外部Java代码调用可能拖慢数据库性能，甚至引发死锁、连接池耗尽等问题。

替代每日全量加载的优质方案 #

1. 定时任务分批精准处理 #

放弃全量扫描逻辑，改为按到期时间精准查询+分页分批处理：

• 选择系统低峰时段（比如凌晨）执行定时任务，通过SQL仅查询当天到期且状态仍为有效的通行证：

  SELECT id FROM pass WHERE validity_time <= CURRENT_TIMESTAMP AND status = true LIMIT 1000
  

• 每次处理1000条（可根据系统性能调整批次大小），处理完一批后再查询下一批，直到没有符合条件的数据为止。
• 优势：仅加载需要处理的目标数据，彻底规避百万级数据一次性加载带来的内存、数据库压力，实现简单，对现有代码改动极小。

2. 延迟队列精准触发 #

这是更现代化、高效的方案，核心逻辑是提前规划任务，到期自动触发：

• 用户订阅通行证时，根据日/周/月卡的类型计算出精确到期时间，将通行证ID和到期时间存入延迟队列：
  • 基于Redis ZSet实现：把到期时间作为score，通行证ID作为value，每分钟扫描一次ZSet中score小于当前时间的元素，取出后执行失效+发短信逻辑；
  • 基于消息队列延迟功能：比如RabbitMQ的延迟交换器、RocketMQ的延迟消息，直接将处理任务发送到对应延迟级别的队列，到期后自动推送给消费端执行业务逻辑。
• 优势：无需全量扫描，仅处理到期的通行证，性能开销极低，完美适配百万级用户规模，触发时机精准。

3. 时间轮调度框架 #

如果需要自研轻量调度系统，可以采用时间轮方案（如Netty的HashedWheelTimer）：

• 将每个通行证的到期任务放入时间轮的对应槽位，当时间轮转动到对应槽时，自动执行处理逻辑；
• 注意：需要额外实现任务持久化逻辑，避免服务重启后丢失未执行的到期任务。
• 优势：内存占用低，调度效率高，适合承载大量延迟任务的场景。

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