在面试中，面试官往往不满足于听到“使用了 Redis 做缓存”这一句套话。他们更关心的是：当业务逻辑变得复杂时，你是如何保证数据一致性的？如何避免缓存穿透和击穿？特别是在电商这种高并发场景下，订单状态的流转是考察分布式系统理解深度的试金石。
本文将基于一个真实的电商订单业务场景——“订单创建后 30 分钟未支付自动取消”，带你从零开始构建一套基于 Redis 的缓存架构。我们将深入探讨如何利用 EXPIRE 指令、延迟队列以及 Lua 脚本，解决状态同步与性能瓶颈问题。读完本文，你不仅能掌握具体的实现代码，更能理清在分布式环境下处理有状态业务的底层逻辑。
业务痛点与核心难点分析
首先明确我们的业务目标：用户下单后，订单状态为“待支付”。如果 30 分钟内未支付，系统需自动将订单状态更新为“已取消”，并释放库存。
在这个场景中，直接挑战传统 MySQL 轮询方案的问题在于性能与资源消耗。假设每天有百万级订单，如果通过定时任务每秒钟扫描一次数据库查找超时订单，不仅数据库压力巨大，而且存在时间窗口误差（即扫描间隔内的订单无法及时取消）。
引入 Redis 后，我们面临两个核心难点：
- 原子性操作：取消订单涉及修改 Redis 中的缓存状态和 MySQL 中的持久化数据。如果只改了一边怎么办？
- 精准延时触发：我们需要在精确的 T+30min时刻触发任务，而不是简单的周期性轮询。
传统的方案是使用 SET KEY VALUE EXPIRE配合消息队列的死信特性（如 RabbitMQ TTL），但为了展示 Redis本身的强大能力并降低系统复杂度（少依赖一个 MQ），这里我们采用 **Redis Sorted Set (ZSet)**作为简易的延迟队列来实现。这种方式虽然比专业 MQ轻量级功能少，但在中小规模或特定场景下极具优势且便于面试阐述原理。
ZSet 延迟队列的实现原理
为什么选择 ZSet？因为 ZSet可以将分数（score）设置为时间戳。我们可以将当前时间 + 30分钟作为 score，将 OrderID作为 member存入 ZSet中。然后启动一个后台线程（Worker），定期从 ZSet头部获取 score < current_time的记录进行消费。
Worker消费逻辑设计
Worker线程不能死循环空转，也不能频繁阻塞导致响应慢最佳实践是使用 BLPOP或者结合 ZRANGEBYSCORE加短睡眠机制。考虑到精度要求不是毫秒级的严苛实时性（比如允许秒级延迟），我们可以每秒执行一次查询处理超时的批量任务批处理可以显著减少网络IO次数）。
以下是核心 Java伪代码演示了如何初始化延迟任务以及 Worker如何消费：```java @Service public class OrderDelayService { @Autowired private StringRedisTemplate redisTemplate;
private static final String DELAY_QUEUE_KEY = "order:delay:queue";
private static final int EXPIRE_SECONDS = 1800; // 30 minutes
/**
*下单成功后调用此方法放入延迟队列
*/
public void addDelayTask(String orderId) {
long currentTime = System.currentTimeMillis();
long expireTime = currentTime + EXPIRE_SECONDS * 1000L;
// Score设为绝对时间戳, Member设为OrderId
//使用ZADD命令加入ZSet, NX表示仅当member不存在时添加,防止重复添加
Boolean result = redisTemplate.opsForZSet()
.add(DELAY_QUEUE_KEY, orderId, expireTime);
if(result != null && result) { log.info("Order [{}] added to delay queue, expires at {}", orderId, new Date(expireTime));
} else { log.warn("Order [{}] already exists in delay queue or add failed", orderId);
}
}
} @Component @Slf4j public class OrderTimeoutWorker { @Autowired private StringRedisTemplate redisTemplate; /** *使用@Scheduled每秒执行一次 *注意：在高并发下需考虑集群部署时的分布式锁问题 */ @Scheduled(fixedRate = 1000) public void processTimeoutOrders() { long now = System.currentTimeMillis(); //获取所有Score小于当前时间的成员, Limit限制单次最大处理数量防止雪崩 Set<ZSetOperations.TypedTuple> expiredOrders = redisTemplate.opsForZSet() .rangeByScoreWithScores("order:delay:queue", Double.NEGATIVE_INFINITY, now, Limit.limit().count(10)); if (expiredOrders == null || expiredOrders.isEmpty()) return; for (ZSetOperations.TypedTuple tuple : expiredOrders) { String orderId = tuple.getValue(); //关键步骤:必须再次校验! //因为可能在Worker取到之前用户已经支付了 if (!isOrderPaid(orderId)) { cancelOrder(orderId); } //无论是否取消,都必须从队列中移除该记录 boolean removed = redisTemplate.opsForZSet().remove("order:delay:queue", orderId) > 0; if (removed) log.debug("Removed order [{}] from delay queue", orderId);
}
}
private boolean isOrderPaid(String orderId) { //查MySQL或查Redis标记位 return orderMapper.selectStatus(orderId).equals(OrderStatus.PAID);
}
private void cancelOrder(String orderId) { //调用实际的业务服务去更新DB和清理缓存
orderService.executeCancel(orderId);
}
} 这里有一个非常关键的细节容易被忽略：**幂等性与状态二次校验**。在 Worker拿到orderId准备取消时，必须重新检查该订单的最新状态。因为在 `rangeByScoreWithScores`取数据和真正执行 `cancelOrder之间可能存在毫秒级甚至秒级的时间差用户可能恰好在这期间完成了支付如果没有二次校验会导致误杀已支付的订单一这在生产环境中是严重的P1事故## Lua脚本保证原子性与防超卖思考很多读者可能会问为什么不直接在Redis里存一个过期标记然后让前端轮询或者后端定时任务去扫这个标记而要用这么复杂的ZSet+Worker模式其实这里涉及到架构权衡如果我们只是为了演示最简单的TTL过期使用SET KEY VALUE EXPIRE即可当Key消失时我们认为超时但这种模式下有一个致命缺陷：**我们无法知道是谁触发的过期也无法执行复杂的副作用操作比如扣减库存计数或发送通知）**Key消失只是被动事件如果要主动触发后续动作就必须依赖外部的监听机制而这通常就需要Pub/Sub或者像上面的ZSet这种显式的队列结构此外在面试中被问到“如何防止库存超卖”时可以顺势引出Lua脚本的应用场景例如在真正扣减库存前可以使用Lua脚本原子性地检查并扣减库存代码如下lua -- stock.lua -- KEYS[1]: stock:key -- ARGV[1]: amount local stock = tonumber(redis.call('get', KEYS[1])) or -1 if stock < tonumber(ARGV[1]) then return -1 end redis.call('decrby', KEYS[1], ARGV[1]) return tonumber(ARGV[1])```这段脚本确保了检查和扣减在一个原子操作中完成避免了并发下的超卖问题虽然这与延时取消不是直接相关但它展示了我们在设计Redis架构时对原子性的整体考量##方案对比与选型依据为了更清晰地理解为何在上述场景中选用ZSet而非其他方案下表对比了三种常见延时任务的实现方式|维度 | Redis Zset + Worker | RocketMQ/RabbitMQ死信 | MySQL定时轮询 |---|---|---|---|| 实现复杂度 |中等需自行维护Worker稳定性|低配置Topic即可|极低仅需CRUD|| 精度 |取决于扫描频率秒级|较高依赖MQ机制|低取决于扫描间隔|| 可靠性 |依赖Redis持久化RDB/AOF若节点宕机可能丢数据除非集群高可用|高消息落盘持久化能力更强|极高数据在主库|| 扩展性 |较差单点Worker需加锁协调多实例消费困难|好天然支持水平扩展消费者组容易横向扩容一般受限于DB连接池|| 适用场景|中小流量对实时性要求非极端严苛的场景|大规模金融级交易要求极高可靠性不引入额外中间件简单CRUD场景通过对比可以看出没有银弹技术选型必须基于团队技术栈储备和业务规模对于初创团队或小中型电商为了避免维护Kafka/RocketMQ的重运维负担使用Redis Zset是一种性价比极高的选择只要做好Worker的幂等设计和异常重试即可满足绝大部分需求##小结与下一步建议回顾本文我们从电商订单超时取消这一具体痛点出发拆解了如何利用Redis Sorted Set构建轻量级延迟队列重点强调了以下三个关键点第一是二次校验的重要性任何异步任务在执行前都必须确认前置状态未发生变更这是分布式系统中避免脏写的基本原则第二是原子性的边界区分清楚哪些操作可以在内存中通过Lua保证原子性哪些必须下沉到数据库层面第三是技术选型的权衡意识不要盲目追求新技术要根据团队规模和运维能力选择合适的组件对于准备面试的你建议在掌握上述案例后进一步延伸学习以下内容一是研究如何在多台服务器部署该Worker时使用Redis分布式锁Redlock或外部协调者如Zookeeper防止重复消费二是探索如何将此模式升级为基于RocketMQ的死信消息以应对更高流量三是深入学习Cache Aside Pattern的一致性策略了解什么是先更新DB还是先删Cache以及在并发下的竞态条件解决方法希望这篇基于真实工作流的复盘能帮助你建立起完整的架构思维框架而不仅仅是记忆几个API命令
本文参考文献：
http://www.hncyxsy.com/juejin-17cbybhmy.html
