Redis 连接从关闭事件中消失 [英] Redis connection gone from close event

问题描述

在我们的 redis 配置中，我们设置了超时时间:7 秒

In our redis configuration we have set timeout: 7 seconds

在node_redis中，我们将redis连接就绪和结束事件处理为

In node_redis We handle redis connection ready and end event as

client.on("ready", function() {
      logger.info("Connection Successfully Established to ", this.host, this.port);
}
client.on("end", function() {
    logger.fatal("Connection Terminated to ", this.host, this.port);
}

示例日志

[2012-07-11 08:21:29.545] [致命] 生产 - 连接终止结束于 'x.x.x.9' '6399'
[2012-07-11 08:21:29.803] [INFO] 生产 - 成功建立到 'x.x.x.9' '6399' 的连接

[2012-07-11 08:21:29.545] [FATAL] Production - Connection Terminated on end to 'x.x.x.9' '6399'
[2012-07-11 08:21:29.803] [INFO] Production - Connection Successfully Established to 'x.x.x.9' '6399'

但在某些情况下(很可能 redis 关闭连接而不通知客户端)我们看到 命令队列堆积起来，请求花费太多时间来获得响应[直到节点-redis客户端能够感知关闭事件的时间].在所有这些情况下，命令回调都会返回此错误Redis connection has been going from close event.即使经过了这么多的等待.由于没有触发通常的结束事件，因此看起来这不是问题，因为超时.

But in some cases (most probably redis is closing the connection without notifying the client) we see the command queue getting piled up and requests are taking too much time to get the response [till the time node-redis client able to sense the close event]. In all such cases command callback is returned with this error Redis connection gone from close event. even after so much waiting. It looks as if this is not an issue because of timeout since the usual end event wasn't triggered.

问题似乎与此类似 - http://code.google.com/p/redis/issues/detail?id=368

Issue seems to be similar to this - http://code.google.com/p/redis/issues/detail?id=368

这是在 redis 中发生的已知事情吗?

Is this a known thing happening in redis?

有没有办法指定命令的执行[发送和接收回复]不应超过阈值并在这种情况下回复错误，而不是让客户端停顿?

Is there a way to specify that execution of a command [sending and receiving a reply back] should not exceed the threshold and reply with an error in that case, instead of making the client stall?

或者在socket_timeout这样的情况下有没有其他触发关闭事件的方法?

Or is there anyother way of triggering close event in such cases like socket_timeout?

或者我们应该从我们的 redis 方面检查一些东西吗?我们在 debug 级别监控了我们的 redis 日志，我们没有发现与此问题相关的任何有用

Or should we check something from our redis side? We monitored our redis log at debug level and we found nothing useful related to this issue

当我们在调试模式下运行 node-redis 时，我们可以清楚地看到客户端因请求堆积在命令队列中而停滞不前.我们在为什么和队列长度"https://github.com/mranney/node_redis/blob/master/index.js#L110" rel="nofollow noreferrer">flush_on_error 函数.我们已禁用 offline_queuing.

When we run the node-redis on debug mode we are clearly able to see the client getting stalled with the requests getting piled up in the command queue. We logged the why and queue length inside flush_on_error function. We have kept offline_queuing disabled.

示例日志

Redis 连接从关闭事件中消失.离线队列 0命令队列 8

Redis connection is gone from close event. offline queue 0 command queue 8

请求失败的响应时间:30388 ms [这取决于命令队列中的等待时间.第一个排队的人响应时间最长，后面的人更短]

Response time of failed a request: 30388 ms [this varies as per the waiting in the command queue. First queued guy has the max response time and the ones following him lesser]

通常的响应时间:1 毫秒

Usual Resonse time: 1 ms

PS:我们也在 node_redis 中提交了问题

PS: We have filed an issue in node_redis too

推荐答案

关于 oconnecp 的回答，你就不能这样做:

With regards to oconnecp's answer, can't you just do:

setInterval(client.ping(), 1000 * 60 * 30);

这篇关于Redis 连接从关闭事件中消失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！