使用Spring Boot+MySQL能否为记录设置过期时间，自动取消超时未处理请求？

结合你的技术栈，我们根据业务量级提供两种可落地的方案，优先推荐实现成本最低的方案：

方案1：Spring Boot 内置定时任务（中小流量场景首选，无额外依赖） #

适合日请求量低于10万、对超时精度要求允许有30秒以内误差的场景，实现成本为0：

• 先给业务请求表加必要字段：status（枚举值：1=待处理、2=已同意、3=已驳回、4=已超时取消）、create_time（请求发起时间）、update_time
• 启动类添加@EnableScheduling注解开启Spring定时任务能力
• 编写定时任务逻辑，建议每30秒执行一次，直接通过SQL批量更新超时的待处理请求，示例SQL用MySQL8.0+支持的for update skip locked避免并发更新冲突：

UPDATE request 
SET status = 4, update_time = NOW() 
WHERE status = 1 AND create_time < DATE_SUB(NOW(), INTERVAL 2 MINUTE)
FOR UPDATE SKIP LOCKED;

• 对应Java代码示例：

@Component
public class RequestTimeoutHandleTask {

    @Resource
    private JdbcTemplate jdbcTemplate;

    //  cron可配置到application.yml中灵活调整
    @Scheduled(cron = "0/30 * * * * ?")
    @Transactional(rollbackFor = Exception.class)
    public void handleTimeoutRequest() {
        jdbcTemplate.update(
            "UPDATE request SET status = 4, update_time = NOW() WHERE status = 1 AND create_time < DATE_SUB(NOW(), INTERVAL 2 MINUTE) FOR UPDATE SKIP LOCKED"
        );
    }
}

• 集群部署时可以加分布式锁（比如Redis setnx、Redisson锁）控制只有一个节点执行任务；如果使用MySQL5.7版本不支持skip locked，必须加分布式锁避免多个节点重复更新同一批数据。
• 优点：无需引入额外组件、代码量不足50行、运维成本极低，完全满足中小项目需求
• 缺点：超时精度由定时任务周期决定，比如30秒执行一次的话最多有30秒的超时延迟，大流量下频繁扫业务表会有数据库压力

方案2：Redis 延迟队列（中高流量场景首选，精度更高） #

适合日请求量超过10万、对超时精度要求到秒级的场景，对数据库更友好：

• 用户发起请求时，往Redis ZSet中写入一条数据，score为请求发起时间+2分钟的时间戳，value为请求ID
• 后台启动一个定时任务每秒扫描ZSet，取出所有score小于当前时间戳的请求ID，批量更新数据库中对应请求的状态为超时取消，再删除ZSet中已处理的元素
• 兜底方案：服务启动时先扫一次数据库，把所有超时未处理的请求先批量更新，避免Redis数据丢失导致漏处理
• 优点：超时精度可达秒级，不需要频繁扫描业务表，数据库压力极小
• 缺点：需要依赖Redis，需要做Redis持久化保证数据不丢失，增加少量运维成本

不推荐方案说明 #

不要使用JVM内置的DelayQueue实现，服务重启、实例宕机、扩容都会导致延迟任务丢失，可靠性完全不符合生产要求

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