jedis无内置errorhandler,需手动实现断线重连:用while(true)循环捕获jedisconnectionexception,每次新建jedispubsub实例并全量重订阅channel列表,避免状态残留和漏收。

Jedis 里没有内置的 ErrorHandler 机制来接管订阅断连。它不像 go-redis 或 Lettuce 那样支持注册连接异常监听器,Jedis.subscribe() 是阻塞式调用,一旦底层 Socket 断开,就会抛出 JedisConnectionException 并退出 —— 这个“退出”不是回调通知,而是线程直接中断,你必须自己捕获、重试、重建连接和重订阅。
为什么不能靠 try-catch + close + getResource 就完事
常见写法是捕获异常后 jedis.close() 再 pool.getResource(),但问题在于:
-
JedisPubSub实例是状态绑定的:它内部维护着订阅状态(比如已订阅哪些 channel),但断连后这个对象不可复用,必须新建一个 -
jedis.subscribe()一执行就阻塞,不会返回连接句柄;重连后若不重新 new 一个JedisPubSub,旧实例可能还在监听已失效的连接,导致消息丢失或静默失败 - 如果多个 channel 同时订阅,断连后只重订其中一个,其余 channel 就永远漏收 —— 必须显式保存 channel 列表并全量重订
如何手动模拟 ErrorHandler 行为
本质是把「异常感知 → 清理 → 重建 → 重订阅」这一串动作封装成可复用逻辑,关键点有三个:
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
while(true)包裹整个订阅流程,让线程持续存活 - 每次循环都 new 一个新的
JedisPubSub实例,避免状态残留 - 把要订阅的 channel 列表抽成变量(如
String[] channels = {"ch1", "ch2"}),断连后直接传给新subscribe()
示例片段:
while (true) {
Jedis jedis = null;
try {
jedis = pool.getResource();
jedis.subscribe(new JedisPubSub() {
@Override
public void onMessage(String channel, String message) {
// 处理消息
}
// 必须重写 onSubscribe/onUnsubscribe 等,否则断连时无法感知
}, channels);
} catch (JedisConnectionException e) {
log.warn("Subscription broken, will reconnect...", e);
} finally {
if (jedis != null && jedis.isConnected()) {
jedis.close(); // 注意:这里 close 不等于 unsubscribe,只是归还连接
}
}
// 自动延时再试,避免 CPU 空转
try { Thread.sleep(1000); } catch (InterruptedException ignored) {}
}
容易被忽略的两个细节
一是 JedisPubSub.onPUnsubscribe() 和 onUnsubscribe() 不代表断连,只是用户主动 unsubscribe();真正断连时,onPMessage() 等方法根本不会被调用 —— 所以不能依赖这些回调做重连判断。
二是阿里云 Redis 实例默认开启 timeout(如 300 秒),且网络抖动时可能触发 READONLY You can't write against a read only slave 类错误;这类错误不属于 JedisConnectionException,需额外 catch JedisDataException 并统一走重连路径。










