有时候大意总会导致故障的出现,最近一个小小问题,我也记录一下吧
在就要公司框架自己写了个redis访问dao,然后过去一段时间后线上出现过一次redis不能获取连接的频繁报错,然后当时重启恢复但是没有细跟,然后到了昨天一个happy的周末又出现这个频繁报错信息了并且有影响到线上接口了。。。。
然后定位了下,应该我写的dao里的pipeline因为查询超时异常导致没有走到pipeline的释放操作,这样累积起来就恶性循环了,因为资源实现了autoclose接口,所以可以直接套用try-resource的写法解决。
前后对比如下,这个sync也是当时迷惑我的一个地方点进去其实就是close方法,所以没注意到pipeline是一个连接型的,后面要注意这种问题了!
public List<String> pipelineLrange(final Collection<String> keys, final long start, final long end) {
if (smartJedis == null) {
return null;
}
SmartJedisPipeline pipeline = smartJedis.pipeline();
List<String> result = Lists.newArrayList();
List<Response<List<String>>> responseList = Lists.newArrayList();
keys.forEach(key -> responseList.add(pipeline.lrange(key, start, end)));
pipeline.sync();
responseList.forEach(response -> {
result.addAll(response.get());
});
return result;
}
public List<String> pipelineLrange(final Collection<String> keys, final long start, final long end) {
if (smartJedis == null) {
return null;
}
List<String> result = Lists.newArrayList();
try(SmartJedisPipeline pipeline = smartJedis.pipeline()) {
List<Response<List<String>>> responseList = Lists.newArrayList();
keys.forEach(key -> responseList.add(pipeline.lrange(key, start, end)));
responseList.forEach(response -> {
result.addAll(response.get());
});
} catch (Exception e) {
log.error("error pipelineLrange", e);
}
return result;
}

线上系统中,由于自定义Redis DAO的pipeline处理不当,导致查询超时未释放连接,进而引发频繁的Redis无法获取连接错误。通过分析,发现是pipeline的释放操作缺失,形成资源泄露的恶性循环。解决方案是利用try-resource自动关闭机制确保资源释放,避免类似问题的发生。
7064

被折叠的 条评论
为什么被折叠?



