Redis的onExpire过期事件如何确保仅被集群中单个应用实例处理

下面提供3种可落地的实现方案，你可以根据现有业务架构选择适配的方式： #

方案1：基于JGroups集群主节点选举实现（推荐，适配现有集群架构） #

你已经部署了JGroups集群，直接复用JGroups内置的协调者选举能力即可，不需要引入额外依赖：

• 实例启动后通过JGroups通道的getView().getCoordinator()方法获取当前集群主节点，仅当本地实例是主节点时，才注册Redis过期事件监听器
• 监听JGroups的ViewChanged事件，集群节点上下线触发主节点切换时：
  • 若本地实例成为新主，立刻注册Redis过期监听器，启动事件处理
  • 若本地实例从主节点降级为普通节点，销毁已注册的监听器，停止接收过期事件
• 轻量简化版实现：两个实例都注册监听器，处理事件前先判断自身是否是当前主节点，不是就直接跳过处理逻辑，省去监听器注册注销的操作，代码改动更小。
  示例代码片段：

// 全局变量标记当前实例是否为JGroups集群主节点
private volatile boolean isCoordinator = false;

// 监听JGroups集群视图变化，更新主节点标记
@Override
public void viewAccepted(View newView) {
    Address localAddr = channel.getAddress();
    Address coordinatorAddr = newView.getCoordinator();
    isCoordinator = localAddr.equals(coordinatorAddr);
}

// Redis过期事件处理逻辑
public void handleKeyExpireEvent(String expiredKey) {
    // 非主节点直接跳过处理
    if (!isCoordinator) {
        return;
    }
    // 执行业务处理逻辑
}

方案2：基于Redis分布式锁实现（无侵入现有JGroups逻辑） #

如果不想调整现有JGroups相关逻辑，可以在事件处理层加分布式锁判断：

• 所有实例都正常注册Redis过期事件监听器
• 收到过期事件后，以lock:expire:${expiredKey}为锁key，调用Redis的SETNX命令抢锁，锁的过期时间设置为大于业务处理的最大耗时即可（一般30s足够）
• 只有抢锁成功的实例执行业务处理逻辑，处理完成后主动释放锁，若实例崩溃未主动释放，锁到期也会自动释放不会阻塞后续处理
  示例代码片段：

public void handleKeyExpireEvent(String expiredKey) {
    String lockKey = "lock:expire:" + expiredKey;
    // 抢锁，设置30秒自动过期
    Boolean lockSuccess = stringRedisTemplate.opsForValue()
        .setIfAbsent(lockKey, "occupied", 30, TimeUnit.SECONDS);
    if (Boolean.TRUE.equals(lockSuccess)) {
        try {
            // 执行业务处理逻辑
        } finally {
            // 处理完成主动释放锁
            stringRedisTemplate.delete(lockKey);
        }
    }
}

方案3：Redis消息队列中转实现（高可靠场景可选） #

如果怕主节点切换或者锁争抢过程中丢失事件，可以加一层消息队列中转：

• 单独部署一个代理服务，或者选其中一个实例专门接收Redis过期事件，收到后直接写入Redis Stream/List队列
• 集群所有节点争抢消费队列中的消息，Redis队列的特性天然保证每条消息只会被一个消费者抢到，无需额外判断逻辑

注意：无论选择哪种方案，都要确保Redis的过期事件通知已经开启，即redis.conf中notify-keyspace-events配置包含Ex参数，否则Redis不会对外推送key过期事件。

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