在我们的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] [FATAL]生产 - 连接终止端上为 'xxx9' '6399'
[2012-07-11 08:21:29.803] [INFO]生产 - 连接成功建立 'xxx9' '6399'
但在某些情况下(最有可能的Redis正在关闭不通知客户端的连接),我们看到的命令队列越来越越积越多,并请求占用过多的时间来作出答复,直到时间节点Redis的客户能够感知的关闭事件]。 在所有这些情况下命令回调返回与此错误Redis connection gone from close event
。 即使经过了这么多的等待。 这看起来好像这是因为超时而不是一个问题,因为通常的结束事件不会被触发。
问题似乎与此类似- http://code.google.com/p/redis/issues/detail?id=368
这是一个已知的事情在发生redis的?
是否有指定命令的执行方式[发送和接收应答返回]在这种情况下应不超过阈值,并回复一个错误,而不是使客户失速?
或者有没有在这样的情况下,像socket_timeout触发接近事件的任何其它的办法吗?
或者,我们应该检查从我们的Redis侧的东西吗? 我们监控Redis的日志在debug
水平,我们没有发现任何有用的与此相关的问题
当我们运行在调试模式节点redis的我们也清醒地看到客户越来越停滞在命令队列中的请求得到越积越多。 我们记录的原因和队列长度内flush_on_error功能。 我们已经把offline_queuing禁用。
示例日志
Redis的连接从关闭事件了。 离线队列0命令队列8
失败的请求的响应时间:30388个MS [此变化按照在命令队列的等待。 第一个排队的人有最大的响应时间和那些跟随他较少]
通常Resonse时间:1毫秒
PS:我们已经提交的问题中node_redis太