【Redis】性能优化建议

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(); 
}

连接池参数含义：

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

优化建议：

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以内，实际也和元素字节数有关)。注意两者不同：

原生是原子操作，pipeline是非原子操作。
pipeline 可以打包不同的命令，原生做不到
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加密访问