redis常见异常

一、连接池

1、maxTotal

JedisPool默认的maxTotal=8，下面的代码从JedisPool中借了8次Jedis，但是没有归还，当第9次(jedisPool.getResource().ping())

执行命令如下：
Jedis jedis = null;
try {
    jedis = jedisPool.getResource();
    //具体的命令
    jedis.executeCommand()
} catch (Exception e) {
    //如果命令有key最好把key也在错误日志打印出来，对于集群版来说通过key可以帮助定位到具体节点。
    logger.error(e.getMessage(), e);
} finally {
    //注意这里不是关闭连接，在JedisPool模式下，Jedis会被归还给资源池。
    if (jedis != null) 
        jedis.close();
}

业务并发量大，maxTotal确实设置小了。

举个例子：

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

那么理论上需要的资源池大小是50000 / 1000 = 50个，实际maxTotal可以根据理论值进行微调。

 

二、最佳实践

1、一定要进行Master-slave主从同步配置，在出现服务故障时可以切换。

2、在master禁用数据持久化，只需要在slave上配置数据持久化

3、物理内存+虚拟内存不足，这个时候dump一直死着，时间久了机器挂掉。这个情况就是灾难！

4、当Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了，就开始做swap，内存碎片大

5、当达到最大内存时，会清空带有过期时间的key，即使key未到过期时间。

6、redis与DB同步写的问题，先写DB，后写redis，因为写内存基本上没有问题（这个涉及到一致性，高并发场景有点复杂）。