redis实现订单自动过期有三种方式：1. sorted set（推荐，分布式友好），以订单id为member、到期时间戳为score，定时扫描并原子处理；2. key过期事件监听，需配置notify-keyspace-events ex并订阅expired频道，响应快但可能丢事件；3. redisson rdelayedqueue，开箱即用但需注意版本兼容性；均需保障幂等性、状态校验与宕机恢复。
Redis 本身不直接提供延时队列功能，但可以通过三种主流方式可靠实现订单自动过期：基于 Sorted Set（zset）、基于 Key 过期事件监听、或借助 Redisson 封装的延迟队列。其中 zset 方案最常用、最稳定，适合大多数订单超时场景。
用 Sorted Set 实现（推荐，分布式友好）
核心思路是把订单 ID 作为 member，订单的到期时间戳（毫秒级）作为 score 存入 zset。系统定期或用守护线程拉取已到期的订单执行取消逻辑。
- 订单创建时：执行
ZADD order_delay_queue <expire_timestamp><order_id></order_id></expire_timestamp> - 检查过期订单：用
ZRANGEBYSCORE order_delay_queue -inf <now_timestamp></now_timestamp>获取所有已到期的 order_id - 处理后批量移除：对每个已处理的 order_id 执行
ZREM order_delay_queue <order_id></order_id> - 建议搭配 Lua 脚本原子执行“查询+删除”，避免重复消费
- 需独立线程或定时任务（如 Spring @Scheduled 每 10–30 秒扫描一次），不能依赖实时触发
用 Key 过期事件监听（轻量但有约束）
为每个订单 key 设置过期时间（如 SETEX order:123 1800 "pending"），再开启 Redis 的键空间通知，监听过期事件。
- 必须在 redis.conf 中配置：
notify-keyspace-events Ex（或运行时执行CONFIG SET notify-keyspace-events Ex） - 应用订阅频道
__keyevent@0__:expired（0 是数据库编号） - 收到
order:123过期消息后，立即调用取消逻辑 - 优点是响应快、无轮询；缺点是事件可能丢失（如 Redis 重启期间）、不保证 100% 可靠，且需额外保障幂等性
用 Redisson 的 RDelayedQueue（开箱即用）
Redisson 封装了底层细节，提供类似 JDK DelayQueue 的语义，自动管理 zset + 队列消费线程。
- 引入依赖：
redisson-spring-boot-starter - 获取延迟队列：
RBlockingDeque<string> queue = redisson.getBlockingDeque("order_cancel_queue"); RDelayedQueue<string> delayed = redisson.getDelayedQueue(queue);</string></string> - 投递任务：
delayed.offer("order_123", 30, TimeUnit.MINUTES); - 消费端从
queue.take()获取，无需手动查时间、删 key - 适合快速落地，但要注意 Redisson 客户端版本兼容性和连接稳定性
关键注意事项
无论选哪种方式，都要考虑：
- 数据一致性：订单取消前，务必校验当前状态是否仍为“待支付”，防止支付成功后又被误取消
- 重复处理：消费逻辑必须幂等（例如用 Redis SETNX 标记“已处理”，或数据库乐观锁更新状态）
- 宕机恢复：zset 和过期监听方案都天然支持服务重启后继续处理（zset 数据在 Redis 中持久化；未消费的过期事件虽不重发，但可通过启动时扫描 Redis 中未支付订单兜底）
-
性能边界：zset 扫描不要用
ZRANGEBYSCORE ... +inf全量拉取，应加 limit 控制单次处理数量，避免阻塞
