问题描述:
日前,生产环境发现有个服务redis连接出现异常,排查过程中发现,redis确实存在read time out的异常问题;奇怪的是:从打印日志来看,redis-keyA居然取到了keyB的值,当下怀疑是不是redis配置的问题;
原因分析:
结合本身问题以及网上经验的借鉴,总结如下:
- JedisUtil里面在使用完Jedis 后释放资源的方式不安全,会在有异常情况下没有释放干净,导致会被别的线程使用,从而导致别的线程使用了里面的数据;
修复之前的释放redis资源代码如下:
/**
* 将连接返回给连接池
*/
public void closeSharedJedis(ShardedJedis shardedJedis) {
if (null != shardedJedis) {
shardedJedisPool.returnResourceObject(shardedJedis);
}
}
- redis连接出现的异常是可能是因为:(a.有阻塞;2.配置的超时时间太短;3.网络抖动;4.主从切换),从而引发了原因1;
解决方案:
把不安全的释放shardedJedisPool.returnResourceObject(jedis); 改成 jedis.close();
/**
* 将连接返回给连接池
*/
public void closeSharedJedis(ShardedJedis shardedJedis) {
if (null != shardedJedis) {
shardedJedis.close();
}
}
总结:
- 自Jedis3.0版本后jedisPool.returnResource()遭弃用,官方重写了Jedis的close方法用以代替,参考文档:https://blog.csdn.net/u013063153/article/details/70266167?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1
- 多个项目,部分项目使用redistemplete方式配置的从未出现过此类问题,所以能用封装的轮子就不要自己造轮子;