1.redis使用中的深坑monitor命令
事情的原由开启redis的monitor命令，为然后把日志出入到磁盘中，方便查询系统bug。到了第二天下午2点左右，整个平台开始出现大面积的崩溃，通过报警发现redis的cpu占用达到99%，但是不知道由什么引起的，随后开始google 发现网上已经有人遇到相同的问题。他说的原因就是monitor，随后我们感觉关闭了monitor命令 cpu一下子恢复正常 从99%降到33%，以下是monitor命令的截图正常的情况cpu占用39%
image.png
当开启monitor命令，如下图
image.png
redis的cpu占用瞬间从39%变成85%。为什么说redis的cpu占用达到99%平台就会卡住，因为redis是单核所有系统操作redis都被阻塞了，导致一系列的雪崩。
2.redis使用中的深坑keys命令
系统有个业务场景是这样的，需要推送通知给所有的在线客服，我们一个程序员写了这样的代码
Jedis jedis = CacheUtils.getJedis();
try{
List list = jedis.keys("online.kf.*");
.......循环list 执行推送业务.....
}finally{
CacheUtils.returnJedis(jedis);
}
看上去代码没有毛病，但是发布到了线上系统开始崩溃，又是一连串的雪崩。。。 o(︶︿︶)o唉 大家不要笑话我们的系统架构，没办法系统还在改造中。通过redis的执行slowlog get 10 分析执行查询时间发行keys命令执行长达1秒钟，也就是说1秒钟内所有操作redis的系统将被阻塞。。。。 好可怕啊有木有⊙♂⊙。。。
image.png
上图是我们生产环境执行的keys时间将近2秒钟，keys是时间复杂度是O(N)， N 为数据库中 key 的数量，redis的官方给出了使用keys的一个警告。
image.png
3.redis周期性的抛出Could not get a resource from the pool
原由是客户度去jedispool获取jedis的时候发现jedis已经被其他线程全部取走，然后当前线程会进入等待，等待时间超过maxActive将会抛出Could not get a resource from the pool，造成这点的原因我遇到了两种。
1.由于系统的并发量增加导致的瓶颈，解决方案 调整maxActive的大小、调整MaxTotal的大小、testOnBorrow为false testOnReturn为false 。
testOnBorrow、testOnReturn这两个参数的作用是从jedispool获取jedis 和释放jedis的会ping一下redis，如果ping不通则抛出异常，所以这里造成了资源的两次浪费。╮(╯_╰)╭
@Override
public boolean validateObject(PooledObject<Jedis> pooledJedis) {
final BinaryJedis jedis = pooledJedis.getObject();
try {
HostAndPort hostAndPort = this.hostAndPort.get();
String connectionHost = jedis.getClient().getHost();
int connectionPort = jedis.getClient().getPort();
return hostAndPort.getHost().equals(connectionHost)
&& hostAndPort.getPort() == connectionPort && jedis.isConnected()
&& jedis.ping().equals("PONG");
} catch (final Exception e) {
return false;
}
}
2.内网带宽满被占用满。解决方案 网卡把千兆网卡换成万兆完美解决。
内网服务之间消息大量的传输沾满了整个带宽导致应用程序向redis发送请求的时候卡了，所以导致异常╮(╯_╰)╭
网友评论