jedis 的 Unexpected end of stream 解决方案

版权声明:本文为博主原创文章,如需转载,请写明出处, 尊重他人即尊重自己(^_^)。 https://blog.csdn.net/aubdiy/article/details/53511410

jedis 的 Unexpected end of stream 解决方案

  • redis 服务端版本号:2.8.X
  • Jedis 客户端版本号:2.8.1
  • 单线程、无并发操作

Jedis单链接、JedisPool、ShardedJedisPool,无论使用哪一种方式对 redis 服务进行操作,均出现了 Unexpected end of stream 的问题。

通过查看源码发现,报错具体位置是:RedisInputStream 类的 ensureFill() 方法

private void ensureFill() throws JedisConnectionException {
    if (count >= limit) {
      try {
        limit = in.read(buf);
        count = 0;
        if (limit == -1) {
          throw new JedisConnectionException("Unexpected end of stream.");
        }
      } catch (IOException e) {
        throw new JedisConnectionException(e);
      }
    }
  }

解决方案:

第一步,检查 redis config 中的 client-output-buffer-limit 配置

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 0 0 0
client-output-buffer-limit pubsub 0 0 0

请根据实际情况合理设置Redis输出缓冲区限制,确定不是因为缓冲区太小,导致链接关闭,进而引起 Unexpected end of stream ,可以临时都设置成 “0(关闭缓冲区限制)” 来验证此种场景

第二步,检查 redis config 中的 timeout 配置

当此时间设置过短时,同一个 jedis 链接,两次访问 redis 服务的时间间隔 > ${timeout} , 服务端会单方关闭这个jedis链接,第二次使用这个jedis对象 操作 redis 时,会发生 Unexpected end of stream , 可以将其设置成“0(无过期)”来验证此种场景

第三步,优化客户端代码,增加重试机制

经过前两步的调试,根据业务实际情况,调整配置,但这样并不能完全杜绝 Unexpected end of stream 的发生,比如 “网络抖动”之类的场景下,依然会发生此问题(实际生产环境中,此种情况发生概率极低),
但是为了防止此异常引起 jvm宕机,建议在代码层面上增加加重试机制。

话外篇:

使用 redis 做存储层时,有可能出现数数据不一致的情况( redis 无事务)

参考:

https://github.com/xetorthio/jedis/issues/932

https://github.com/xetorthio/jedis/issues/1029

展开阅读全文

没有更多推荐了,返回首页