版权声明：本文为博主原创文章，如需转载，请写明出处， 尊重他人即尊重自己（^_^）。 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 无事务）