Question

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

在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] [致命]生产 - 连接已终止   结束'x.x.x.9''6399'
  [2012-07-11 08：21：29.803] [INFO]制作 - 连接成功建立为'x.x.x.9''6399'

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

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

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

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

或者在socket_timeout等情况下是否还有其他触发close事件的方法？

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

当我们在调试模式下运行node-redis时，我们显然能够看到客户端因命令队列中堆积的请求而停滞不前。我们在why and queue length内部记录flush_on_error。我们一直禁用offline_queuing。

示例日志

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

请求失败的响应时间：30388 ms [这根据命令队列中的等待而变化。第一个排队的人有最大的响应时间和跟随他的人较少]

通常的Resonse时间：1 ms

PS：我们在node_redis中也提交了issue

Answer 1

我们也遇到了一堆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分钟只能进行一次通话，这对性能来说应该不是问题;）

Answer 2

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

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

Redis连接从关闭事件中消失了

2 个答案: