关于Pull Message Task的 Reconnection问题疑惑

[eddieran]

关于 RedisMessagePullTask 的初始化实现当中
会默认开启重连检测
https://github.com/xiaolyuh/layering-cache/blob/master/layering-cache-core/src/main/java/com/github/xiaolyuh/listener/RedisMessagePullTask.java#L44C9-L44C25

// 4. 重连检测
reconnectionTask(initialDelay, delay);

但是在重连检测里面，我看似乎每一次都会每隔几秒就建立一个新的连接？

@Override
    public void subscribe(RedisMessageListener messageListener, String... channels) {
        try {
            StatefulRedisPubSubConnection<String, String> connection = this.clusterClientPubSub.connectPubSub();
            logger.info("layering-cache和redis创建订阅关系，订阅频道【{}】", Arrays.toString(channels));
            connection.sync().subscribe(channels);
            connection.addListener(messageListener);
        } catch (SerializationException e) {
            throw e;
        } catch (Exception e) {
            throw new RedisClientException(e.getMessage(), e);
        }
    }

在pub/sub 的订阅初始化，这里我看 connection会持有对应的messageListener的bean，看起来连接也不会释放？
是否有连接一直堆积越建立越多的情况呢

[dropdown-hue]

这块会出问题的，不断的重连。。。redis连接数被打满，造成系统崩溃。具体啥原因不知道，没查到。我直接把重连的定时任务给去掉的。lettuce的连接本身就支持重连。

[1025044866xxy]

这块会出问题的，不断的重连。。。redis连接数被打满，造成系统崩溃。具体啥原因不知道，没查到。我直接把重连的定时任务给去掉的。lettuce的连接本身就支持重连。

不对吧，订阅拉取数据的时候，会先更新push time，有数据再更新pull time。
本地有个定时job 7s一次，拉取数据，有数据更新pull time。
判断逻辑是 pull time - push time > 10s的时候，需要重连。此时说明数据都是定时拉取的，订阅失效了。

[1025044866xxy]

这块会出问题的，不断的重连。。。redis连接数被打满，造成系统崩溃。具体啥原因不知道，没查到。我直接把重连的定时任务给去掉的。lettuce的连接本身就支持重连。

不对吧，订阅拉取数据的时候，会先更新push time，有数据再更新pull time。 本地有个定时job 7s一次，拉取数据，有数据更新pull time。 判断逻辑是 pull time - push time > 10s的时候，需要重连。此时说明数据都是定时拉取的，订阅失效了。

图一为订阅，先更新push time。图二为job定时拉取，图三为有数据更新pull time。