Redis进阶-JedisPool参数优化 & 如何合理估算核心参数 & redis连接池预热

Pre

Redis Version : 5.0.3

maven依赖:jedis 2.9.0

<dependency>
       <groupId>redis.clients</groupId>
       <artifactId>jedis</artifactId>
       <version>2.9.0</version>
   </dependency>

JedisPoolConfig & JedisPool

如果我们选择Jedis作为客户端来操作Redis的话， 操作单节点的Redis，JedisPool & JedisPoolConfig 那肯定要好好地了解一番。 合理的JedisPool资源池参数设置能够有效地提升Redis性能。

查看JedisPool的源码，你会看到好多构造方法中都有GenericObjectPoolConfig

GenericObjectPoolConfig的子类 JedisPoolConfig 我们用的比较多，当然了你也可以直接使用 GenericObjectPoolConfig 来初始化 PoolConfig .

初始化Jedis 如下：

参数说明

Jedis连接就是连接池中JedisPool管理的资源，JedisPool保证资源在一个可控范围内，并且保障线程安全。使用合理的GenericObjectPoolConfig配置能够提升Redis的服务性能，降低资源开销。

GenericObjectPoolConfig 以及他的父类 BaseObjectPoolConfig 有许多属性可以设置。

BaseObjectPoolConfig 默认值都在这里了。

资源设置与使用相关参数

空闲资源检测相关参数

空闲Jedis对象检测由下列四个参数组合完成，testWhileIdle是该功能的开关。

为了方便使用，Jedis提供了JedisPoolConfig，它继承了GenericObjectPoolConfig在空闲检测上的一些设置。

关键参数设置建议

maxTotal（最大连接数）

想合理设置maxTotal（最大连接数）需要考虑的因素较多，如：

• 业务希望的Redis并发量；
• 客户端执行命令时间；

举个例子 Redis资源，例如nodes （如应用个数等） * maxTotal不能超过Redis的最大连接数；

资源开销，例如虽然希望控制空闲连接，但又不希望因为连接池中频繁地释放和创建连接造成不必要的开销。

假设一次命令时间，即borrow|return resource加上Jedis执行命令 （ 含网络耗时）的平均耗时约为1ms，一个连接的QPS大约是1000，而业务期望的QPS是50000，那么理论上需要的资源池大小是50000/ 1000= 50。

但事实上这只是个理论值，除此之外还要预留一些资源，所以maxTotal可以比理论值大一些。这个值不是越大越好，一方面连接太多会占用客户端和服务端资源，另一方面对于Redis这种高QPS的服务器，如果出现大命令的阻塞，即使设置再大的资源池也无济于事。

maxIdle与minIdle

maxIdle实际上才是业务需要的最大连接数，maxTotal 是为了给出余量，所以 maxIdle 不要设置得过小，否则会有new Jedis（新连接）开销，而minIdle是为了控制空闲资源检测。

连接池的最佳性能是maxTotal=maxIdle，这样就避免了连接池伸缩带来的性能干扰。但如果并发量不大或者maxTotal设置过高，则会导致不必要的连接资源浪费。

可以根据实际总QPS和调用Redis的客户端规模整体评估每个节点所使用的连接池大小。

使用监控获取合理值

在实际环境中，比较可靠的方法是通过监控来尝试获取参数的最佳值。可以考虑通过JMX等方式实现监控，从而找到合理值。

常见问题

资源不足

下面两种情况均属于无法从资源池获取到资源。

• 超时

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
…
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)

• blockWhenExhausted 为false，因此不会等待资源释放：

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
…
Caused by: java.util.NoSuchElementException: Pool exhausted
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)

此类异常的原因不一定是资源池不够大，请参见关键参数设置建议中的分析。建议从网络、资源池参数设置、资源池监控（如果对JMX监控）、代码（例如没执行jedis.close()）、慢查询、DNS等方面进行排查。

预热JedisPool

由于一些原因（如超时时间设置较小等），项目在启动成功后可能会出现超时。或者你预估你的应用启动时会有大量的请求过来。。。.

JedisPool定义最大资源数、最小空闲资源数时，不会在连接池中创建Jedis连接。

初次使用时，池中没有资源使用则会先new Jedis，使用后再放入资源池，该过程会有一定的时间开销，所以建议在定义JedisPool后，以最小空闲数量为基准对JedisPool进行预热.

List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
    Jedis jedis = null;
    try {
        jedis = pool.getResource();
        minIdleJedisList.add(jedis);
        jedis.ping();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    } finally {
     // 这里啥都不要做,不要close，否则连接池中只会有1个连接
    }
}
// 统一将预热的连接还回连接池 
for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) {
    Jedis jedis = null;
    try {
        jedis = minIdleJedisList.get(i);
        // 将预热的连接还回连接池 
        jedis.close();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    } finally {
    }
}

总之，要根据实际系统的QPS和调用redis客户端的规模整体评估每个节点所使用的连接池大小。