4

在我们的 redis 配置中，我们设置了 timeout: 7 seconds

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

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] [致命] 生产 - 连接终止于 'xxx9' '6399'
[2012-07-11 08:21:29.803] [信息] 生产 - 连接成功建立到' xxx9' '6399'

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

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

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

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

或者在像socket_timeout这样的情况下还有其他触发关闭事件的方法吗？

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

当我们在调试模式下运行 node-redis 时，我们可以清楚地看到客户端因请求堆积在命令队列中而停滞不前。我们在flush_on_error函数中记录了原因和队列长度。我们一直禁用offline_queuing 。

样本日志

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

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

通常的响应时间：1 毫秒

PS：我们也在 node_redis中提交了一个问题

4

2 回答 2

3

我们也遇到了与 Redis 的连接问题。似乎它会在不告诉客户端的情况下关闭连接。我们注意到这可能是服务器上的超时问题。这是我们使用的解决方案，自 7 月以来我们没有遇到任何问题。

var RETRY_EVERY = 1000 * 60 * 3;
var startTimer = function(){
    console.log('Begin the hot tub!')
    setInterval(function(){
        try{
            client.set('hot',new Date());
            console.log(client.get('hot'))
        }
        catch(e){
            console.log(e);
        }

    },RETRY_EVERY)
}();

考虑到每 3 分钟只有一个电话，性能应该不成问题；）

于 2013-12-20T06:37:09.270 回答
3

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

setInterval(client.ping(), 1000 * 60 * 30);
于 2014-01-04T15:34:45.393 回答