由Redis客户端连接数大小说开去

96
天路72拐
2017.08.24 20:41* 字数 1428

缘起:

redis.clients.jedis.exceptions.JedisConnectionException:Could not get a resource from the pool

生产环境的业务服务器报了大量上面的错误。Jedis无法从连接池中获取一个可用的连接,所有客户端与Redis服务端保持通信的连接都在工作中,没有闲置的连接可以使用。

       目前生产环境每天Redis的QPS在5000左右,连接池配置20个最大连接数貌似是真的很小,是不是增大连接池的配置就解决问题了?出现这个问题的根本原因是:连接池中的Jedis对象是有限的,如果Jedis一直被占用,没有归还,如果这时需要操作redis,就需要等待可用的Jedis,当等待时间超过maxWaitMillis,就会抛出could not get a resource from pool。以下几种场景会出现这个问题:

1.并发实在太高了,连接池中的连接数确实太小了,大量的请求等待空闲的连接。

2.由于Redis是单线程,某个查询太慢,阻塞了其他操作命令的执行。

3.Redis内部问题导致处理客户端的命令慢了,比如RDB持久化时,fork进程做内存快照;AOF持久化时,AOF文件重写时会占用大量的CPU资源;

4.大量key同时过期。

以下数据来自于CAT对缓存的监控数据:蓝线表示出现Could not get a resource from the pool的次数,绿线表示QPS,从图中可以看出随着QPS的升高,出现异常的次数也在增高,难道真的是因为QPS高,连接池数小的原因?

CAT上按照小时为维度获取缓存出现异常的数据如下:

从以下数据可以发现缓存出现异常的时间段都比较集中,而且间隔的时间段貌似存在着某种规律。出现问题的时间段也并不是每天QPS最高的时候,QPS最高的几个时间段反而没有出现任何异常。取了一个出现异常的时间段的缓存情况如下

发现这个时间段有几个比较耗时的操作命令,但是这几个命令在其他时间段最大耗时就10多毫秒。业务上也不存在不合理使用Redis数据结构的问题。是该看看缓存的监控情况了(这一部分图片没截)。

       找运维看了Redis的情况,发现Redis的某个时间段CPU飙到100%了,这个时间段和出现异常的时间段吻合。问题基本已经确认,这个时间段Redis内部一定发生了点什么,导致处理客户端的请求变慢了,导致大量的请求被阻塞,超过maxWaitMillis时,集中出现了大量的Could not get a resource from the pool异常。

      生产环境Redis的持久化策略是AOF,AOF会将所有的写命令按照一定频率写入到日志文件中,随着AOF文件越来越大,里面会有大部分是重复命令或者可以合并的命令(比如100次incr = set key 100),重写可以减少AOF日志尺寸,减少内存占用,加快数据库恢复时间。AOF重写的过程会fork一个子进程,导致CPU飙到100%了。在这种情况下即使增大接池连接数也没什么卵用。这个问题的解决思路是减少AOF重写的频率,两种方式:

1、让Redis决定是否做AOF重写操作,根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个参数,auto-aof-rewrite-percentage:当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之多少时重写;auto-aof-rewrite-min-size:当前aof文件大于多少字节后才触发

2、用crontab定时重写,命令是:BGREWRITEAOF

上面提到慢查询会阻塞Redis,那么业务开发同学在使用时如何避免呢?

1、避免让Redis执行耗时长的命令,绝大多数读写命令的时间复杂度都在O(1)到O(N)之间,O(1)的命令是安全的,O(N)命令在使用时需要注意,如果N的数量级不可预知,应避免使用,如对一个field数未知的Hash数据执行HGETALL/HKEYS/HVALS命令,通常来说这些命令执行的很快,但如果这个Hash中的field数量极多,耗时就会成倍增长

2、避免在使用这些O(N)命令时发生问题主要有几个办法:不要把List当做列表使用,仅当做队列来使用,严格控制Hash、Set、Sorted Set的大小,将排序、并集、交集等操作放在客户端执行,禁止使用KEYS命令

3、避免一次性遍历集合类型的所有成员,而应使用SCAN类的命令进行分批的,游标式的遍历SSCAN/HSCAN/ZSCAN等命令,分别用于对Set/Hash/Sorted Set中的元素进行游标式遍历

4、尽可能使用长连接或连接池,避免频繁创建销毁连接,使用pipelining将连续执行的命令组合执行

日记本
Web note ad 1