【Redis】性能优化建议

2022-11-01 15:00 282阅读 0赞

### 1.使用连接池 ###

> 【推荐】 使用带有连接池的数据库，可以有效控制连接，同时提高效率，标准使用方式：

JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); 
    jedisPoolConfig.setMaxTotal(5); 
    jedisPoolConfig.setMaxIdle(2); 
    jedisPoolConfig.setTestOnBorrow(true);
    
    JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000, null);
    Jedis jedis = null; 
    try {
         
        jedis = jedisPool.getResource(); 
    	// 具体的命令 
        jedis.executeCommand() 
    } catch (Exception e) {
         
        logger.error("op key {} error: " + e.getMessage(), key, e); 
    } finally {
         
        // 注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
        if (jedis != null) 
            jedis.close(); 
    }

连接池参数含义：

<table> 
 <thead> 
  <tr> 
   <th>序号</th> 
   <th>参数名</th> 
   <th>含义</th> 
   <th>默认值</th> 
   <th>使用建议</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>maxTotal</td> 
   <td>资源池中大连接数</td> 
   <td>8</td> 
   <td>设置建议见下面</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>maxIdle</td> 
   <td>资源池允许最大空闲的连接数</td> 
   <td>8</td> 
   <td>设置建议见下面</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>minIdle</td> 
   <td>资源池确保少空闲的连接数</td> 
   <td>0</td> 
   <td>设置建议见下面</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>blockWhenExhausted</td> 
   <td>当资源池用尽后，调用者是否要等待。<br>只有当为true时，下面的maxWaitMillis才会 生效</td> 
   <td>true</td> 
   <td>建议使用默认值</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>maxWaitMillis</td> 
   <td>当资源池连接用尽后，调用者的大等待时间(单位为毫秒)</td> 
   <td>-1：表示永不超时</td> 
   <td>不建议使用默认值</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>testOnBorrow</td> 
   <td>向资源池借用连接时 是否做连接有效性检测(ping)，无效连接会被移除</td> 
   <td>false</td> 
   <td>业务量很大时候建议设置为false(多一次ping的开销)。</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>testOnReturn</td> 
   <td>向资源池归还连接时是否做连接有效性检 测(ping)，无效连接会被移除</td> 
   <td>false</td> 
   <td>业务量很大时候建议设置为false(多一次 ping的开销)。</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>jmxEnabled</td> 
   <td>是否开启jmx监控，可用于监控</td> 
   <td>true</td> 
   <td>建议开启，但应用本身也要开启</td> 
  </tr> 
 </tbody> 
</table>

优化建议：

1）**maxTotal**

最大连接数，早期的版本叫 maxActive 实际上这个是一个很难回答的问题，考虑的因素比较多：

*  业务希望 Redis 并发量
 *  客户端执行命令时间
 *  Redis 资源。例如 nodes(应用个数) \* maxTotal 是不能超过redis的大连接数(maxclients)。
 *  资源开销。例如虽然希望控制空闲连接(连接池此刻可马上使用的连接)，但是不希望因为连接池的频繁释放创建连接造成不必靠开销。

以一个例子说明，假设:

*  一次命令时间（borrow|return resource + Jedis执行命令(含网络) ）的平均耗时约为 1ms，一个连接的 QPS 大约是1000
 *  业务期望的 QPS 是50000

那么理论上需要的资源池大小是 50000 / 1000 = 50个。但事实上这是个理论值，还要考虑到要比理论值预留一些资源，通常来讲maxTotal 可以比理论值大一些。 但这个值不是越大越好，一方面连接太多占用客户端和服务端资源，另一方面对于 Redis 这种高 QPS 的服务器，一个大命令的阻塞即使设置再大资源池仍然会无济于事。

2）**maxIdle 和 minIdle**

maxIdle 实际上才是业务需要的大连接数，maxTotal是为了给出余量，所以maxIdle不要设置过小，否则会有new Jedis(新连接)开销。

**连接池的最佳性能是 maxTotal = maxIdle**，这样就避免连接池伸缩带来的性能干扰。但是如果并发量不大或者 maxTotal 设置过高，会导致不必要的连接资源浪费。一般推荐 maxIdle 可以设置为按上面的业务期望 QPS 计算出来的理论连接数，maxTotal 可以再放大一倍。

minIdle（小空闲连接数），与其说是小空闲连接数，不如说是"至少需要保持的空闲连接数"，在使用连接的过程中，如果连接数超过了minIdle，那么继续建立连接，如果超过了 maxIdle，当超过的连接执行完业务后会慢慢被移出连接池释放掉。

3）**连接池预热**

如果系统启动完马上就会有很多的请求过来，那么可以给 redis 连接池做预热，比如快速的创建一些redis连接，执行简单命令，类似ping()，快速的将连接池里的空闲连接提升到 minIdle 的数量。

示例代码：

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个连接。。 
            // jedis.close(); 
        } 
    } 
    
    // 统一将预热的连接还回连接池 
    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客户端的规模整体评估每个节点所使用的连接池大小。

### 2.选择合适命令 ###

> 【推荐】O(N)命令关注N的数量。

例如 hgetall、lrange、smembers、zrange、sinter 等并非不能使用，但是需要明确N的值。有 遍历的需求可以使用 hscan、sscan、zscan代替。

> 【推荐】禁用命令。

禁止线上使用 keys、flushall、flushdb 等，通过redis的rename机制禁掉命令，或者使用scan的 方式渐进式处理。

> 【推荐】合理使用select。

redis的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。

> 【推荐】使用批量操作提高效率 。

原生命令：例如mget、mset。 
    非原生命令：可以使用pipeline提高效率。

但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)。 注意两者不同：

1.  原生是原子操作，pipeline是非原子操作。
2.  pipeline 可以打包不同的命令，原生做不到
3.  pipeline 需要客户端和服务端同时支持。

> 【推荐】Redis事务功能较弱，不建议过多使用，可以用lua替代。

### 3.选择合适 key 删除策略 ###

> 【推荐】 选择合适的删除策略。

Redis 对于过期键有三种清除策略：

*  被动删除：当读/写一个已经过期的 key 时，会触发惰性删除策略，直接删除掉这个过期 key
 *  主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以 Redis 会定期主动淘汰一批已过期的 key
 *  当前已用内存超过 maxmemory 限定时，触发主动清理策略

注意，当 Redis 运行在主从模式时，只有主结点才会执行被动和主动这两种过期删除策略，然后把删除操作 ”del key” 同步到从结点。

第三种策略的情况如下： 当前已用内存超过 maxmemory 限定时，会触发主动清理策略。所以，我们需要根据自身业务类型，选好 maxmemory-policy(大内存淘汰策略)，设置好过期时间。如果不设置大内存，当 Redis 内存超出物理内存限制时，内存的数据会开始和磁盘产生频繁的交换 (swap)， 会让 Redis 的性能急剧下降。

*  allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
 *  allkeys-random：随机删除所有键，直到腾出足够空间为止。
 *  volatile-random: 随机删除过期键，直到腾出足够空间为止。
 *  volatile-ttl：根据键值对象的ttl属性，删除近将要过期数据。如果没有，回退到 noeviction策略。
 *  noeviction：不会剔除任何数据，拒绝所有写入操作并返回客户端错误信息"(error) OOM command not allowed when used memory"，此时Redis只响应读操作。

默认策略是 volatile-lru，即超过大内存后，在过期键中使用 lru 算法进行 key 的剔除，保证不过期数据不被删除，但是可能会出现OOM 问题。

### 其他 ###

> 【推荐】 避免多个应用使用一个Redis实例。正例：不相干的业务拆分，公共数据做服务化。

> 【推荐】 高并发下建议客户端添加熔断功能(例如netflix hystrix)

> 【推荐】 设置合理的密码，如有必要可以使用SSL加密访问