很多业务系统里都存在这样的需求：订单创建后30分钟未支付要自动关闭，用户注册后要发欢迎邮件，缓存被清理后要同步更新报表。早期做法通常是起一个定时任务，每隔几秒扫一遍数据库，数据量一大就扛不住，实时性也差。其实Redis从2.8版本开始就提供了键空间通知功能，键的过期、删除、修改等操作都能以发布订阅的形式推出来，如果再把这股事件流接入消息队列，就能构建出一套轻量、实时的解耦方案。
键空间通知的底层原理与配置
键空间通知本质上是对Redis发布订阅机制的一种扩展。当某个键的状态发生变化时，Redis会向特定的频道发布一条消息。频道分为两类：一类是键空间通知，频道名格式为__keyspace@前缀加上键名，消息内容是事件类型；另一类是键事件通知，频道名格式为__keyevent@前缀加上事件类型，消息内容是键名。日常开发中用得更多的是键事件通知，因为订阅方通常关心的是“哪些键过期了”，而不是“某个键发生了什么”。
这个功能默认是关闭的，因为它会消耗一定的CPU资源。开启方式是通过config set notify-keyspace-events命令设置参数。参数是一个字符串，由若干字符组成，每个字符代表一类事件。比较常用的组合是Ex，其中E表示启用键事件通知，x表示过期事件；如果还想监听所有写操作，可以用KEA开启全部事件。需要注意的是，这个配置通过命令行设置后重启会失效，想持久化必须写进redis.conf配置文件：
# 命令行临时开启，监听过期事件 config set notify-keyspace-events Ex # redis.conf 中持久化配置 notify-keyspace-events "Ex"
还有一个关键细节容易被忽略：过期键的通知不是在键到期的那一刻立即发出的。Redis对过期键采用惰性删除加定期删除的策略，只有当Redis真正尝试删除这个键时，才会发布expired事件。如果这个键一直没人访问，定期清理任务的扫描周期就决定了通知的延迟上限，通常在秒级，大多数业务场景可以接受，但对时效要求极高的场景要提前评估。
基于Spring Boot监听通知并转发到MQ
监听端的核心是RedisMessageListenerContainer，它内部会维护与Redis的订阅连接。下面给出一个完整的实现，把过期事件捕获后封装成消息发送到RabbitMQ：
@Configuration
public class RedisNotifyConfig {
@Bean
public RedisMessageListenerContainer listenerContainer(
RedisConnectionFactory factory,
KeyExpirationListener listener) {
RedisMessageListenerContainer container = new RedisMessageListenerContainer();
container.setConnectionFactory(factory);
// 订阅0号库的过期事件，模式匹配用PatternTopic
container.addMessageListener(listener, new PatternTopic("__keyevent@0__:expired"));
return container;
}
}
@Component
public class KeyExpirationListener implements MessageListener {
@Autowired
private RabbitTemplate rabbitTemplate;
@Override
public void onMessage(Message message, byte[] pattern) {
String key = new String(message.getBody(), StandardCharsets.UTF_8);
// 只转发业务关心的前缀，避免无关键造成消息洪峰
if (key.startsWith("order:expire:")) {
String orderId = key.substring("order:expire:".length());
rabbitTemplate.convertAndSend("order.exchange", "order.timeout", orderId);
}
}
}这里有个设计要点值得强调：监听器收到事件后不要直接执行业务逻辑，而是原样转发到MQ。原因在于Redis的发布订阅不保证消息可达，如果消费者在重启窗口期内错过事件，消息就永远丢了。把Redis通知当成一个“事件搬运工”，由MQ来负责持久化、重试和削峰，两边的可靠性模型各司其职。业务方（比如订单服务、积分服务、通知服务）只需要消费MQ里的消息，彼此之间完全不用感知对方的存在，这正是解耦的价值所在。
下单时写入带TTL的键也很简单，设置键的过期时间等于业务允许的等待时长即可：
public void createOrder(Order order) {
orderMapper.insert(order);
// 30分钟后过期，触发键过期事件
stringRedisTemplate.opsForValue().set(
"order:expire:" + order.getId(), "1", 30, TimeUnit.MINUTES);
}生产环境必须处理的几个坑
第一个坑是事件丢失。前面提到过，Redis订阅连接断开期间的事件无法补回。兜底方案是引入对账机制：定时任务每隔几分钟扫描数据库中处于“待支付”状态的订单，检查是否超时，作为过期通知的补偿路径。双保险的设计在分布式系统里非常常见，主路径保证实时性，补偿路径保证最终一致性。
第二个坑是Redis集群模式下的订阅问题。Redis Cluster中键会分散在不同节点，订阅客户端必须能收到所有节点的事件。Spring Data Redis的RedisMessageListenerContainer在集群模式下会自动处理订阅拓扑，但如果用的是代理或者Codis这类中间件，就要确认代理是否正确转发了发布订阅消息，否则会出现“部分事件收不到”的诡异现象，排查起来非常费劲。
第三个坑是消息重复和业务幂等。同一条订单超时消息可能因为MQ重试被消费多次，也可能同时被过期通知和对账任务触达。消费方必须做幂等处理，常见做法是用订单状态机做乐观更新，SQL写成update order set status = 'CANCELLED' where id = ? and status = 'PENDING'，只有真正影响行数的那一次消费才算生效，其余的重复请求自然被状态条件挡掉。
最后一个坑是键命名规范。如果Redis里所有业务键的过期事件都被监听端转发，消息量会远超实际需要。坚持用统一前缀（如order:expire:）区分业务键，在监听器里过滤无关事件，能显著降低MQ的压力。整体来看，这套方案用极低的开发成本换来了准实时的延迟订单处理能力，配合对账兜底和幂等设计，完全可以稳定跑在高并发的生产环境里。
Redis键空间通知消息队列系统解耦修改时间：2026-09-04 07:44:34