转载：https://blog.csdn.net/testcs_dn/article/details/43052585
产生此错误的原因通常是：
一、Redis没有启动；
我自己遇到一次这样的问题。汗！
二、由于防火墙原因无法连接到Redis;
1、服务器防火墙入站规则。
2、访问Redis的应用程序所在主机的出站规则。
三、IP地址或端口错误
四、Jedis 对象用完以后，要释放掉,不让会一直占用，所以会出现无法获取新的资源。
五、Spring Boot项目，缺少依赖
如果使用Redis与Spring Boot，也会抛出此异常。
如果你使用的是Spring Boot，那么Redis的依赖是不够的，
您还需要从redis.io手动下载并安装Redis，然后将其从终端运行
me@my_pc:/path/to/redis/dir$ ./src/redis-server ./redis.conf
运行服务器后，您需要在使用Redis的所有应用程序中添加相关行：
application.properties:
spring.redis.host: <yourhost> // usually localhost, but can also be on a LAN
spring.redis.port: <yourport> // usually 6379, but settable in redis.conf
application.yml:
...
spring:
redis:
host: <yourhost> // usually localhost, but can also be on a LAN
port: <yourport> // usually 6379, but settable in redis.conf
六、vm.overcommit_memory = 0，fork失败
使用redis-cli，执行ping命令，异常信息出来了：
(error)MISCONF Redis is configured to save RDB snapshots, but is currently
not able to persist on disk. Commands that may modify the data set
are disabled. Please check Redis logs for details about the error.
然后查看redis日志，出现了
WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
问题已经很清晰了，bgsave会fork一个子进程，因为vm.overcommit_memory = 0，所以申请的内存大小和父进程的一样，由于redis已经使用了60%的内存空间，所以fork失败
解决办法：
/etc/sysctl.conf 添加 vm.overcommit_memory=1
sysctl vm.overcommit_memory=1
链接：http://www.jianshu.com/p/bb552ccc43b9
來源：简书
七、当jedispool中的jedis被取完 等待超过你设置的 MaxWaitMillis 就会抛出Could not get a resource from the pool
八、连接池中空闲的连接过一阵子就会自动断开，但是连接池还以为连接正常
参考配置文件：
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(200);
config.setMaxIdle(50);
config.setMinIdle(8);//设置最小空闲数
config.setMaxWaitMillis(10000);
config.setTestOnBorrow(true);
config.setTestOnReturn(true);
//Idle时进行连接扫描
config.setTestWhileIdle(true);
//表示idle object evitor两次扫描之间要sleep的毫秒数
config.setTimeBetweenEvictionRunsMillis(30000);
//表示idle object evitor每次扫描的最多的对象数
config.setNumTestsPerEvictionRun(10);
//表示一个对象至少停留在idle状态的最短时间，然后才能被idle object evitor扫描并驱逐；这一项只有在timeBetweenEvictionRunsMillis大于0时才有意义
config.setMinEvictableIdleTimeMillis(60000);
JedisPool pool = new JedisPool(config, ip, port, 10000, "密码", 0);
问题原因分析：
redis是我们数据的保管者，我们可以随时存随时取，大的小的，重要的不重要的，它都毫无怨言的帮我们保存着，甚至有些时候，我们变得很懒，存东西进去的时候顺便还贴张纸：“过了一个星期就帮我扔了吧”，对于这些，Redis也都默默的接受了(谁叫Antirez把redis设计的这么好呢)。
这次要写的就是关于这张留言纸的事。
Redis提供了一套“美好”的过期数据清理机制:
主动过期: Redis对数据是惰性过期，当一个key到了过期时间，Redis也不会马上清理，但如果这个key过期后被再次访问，Redis就会主动将它清理掉。
被动过期: 如果过期的Key一直没被访问，Redis也不会一直把它放那不管，它会每秒10次的执行以下的清理工作：
随机从所有带有过期时间的Key里取出20个
如果发现有过期的，就清理
如果这里有25%的Key都是过期的，就继续回到第一步再来一次
这套过期机制设计的很赞，可以这样理解：如果当前有超过1/4的Key是过期的话，就不停地清理，直到只剩下1/4不到的Key是要过期的为止，然后就慢慢地随机抽查着清理。
这个错误是因为JedisPool拿到一个连接后，调用 jedis.ping() 方法没有得到正确的返回”pong”消息，而出现这个问题时，并不是traffic的高峰期，redis的cpu不高，于是程序员很快就怀疑到网络上，难道有”丢包”?
但跑了几天，发现出错的时间固定在某几个时间点(如晚上9点~10点)，莫非是扫地阿姨每天定时在机房打扫卫生，碰着网线了？(有时候不得不佩服程序员的想象力)
然而在一个夜黑风高的晚上，程序员的脑子在这个时候一般是最清醒的，这时告警短信又来了，打开redis监控，像在唯品会上逛街一样，对着redis的各项监控数据逛啊逛，突然，看到有几条Expires的数据，当时的表情只能用看到关注了几天的商品上标了大大”0.1折”时的表情来形容。
接下来的事情，想必大家也都猜到个七七八八了，当然是下单抢购支付了，
脑子里一系列的运算，掐指一算: “这个时间点正好有一大批key过期”，而且都是大的Set集合，每个都有几十万的数据，再一算: “Redis里的大部分需要过期的key就是这些key”。
于是，答案有了，Redis进行被动过期清理时，发现怎么随机，都有超过1/4的Key都是过期的，就忙着不停的删啊删，再加上又都是大集合的删除，O(N)的操作复杂度，无奈，
等redis删完时，客户端那边的命令都等超时了。
原因找到了，如何解决？看业务场景吧，对于我们的场景，
做法是将过期时间设长一点，然后把这些可以删掉的Key标记一下，丢到一个后台线程那里分页删Set里的数据，这样就算redis再做过期操作，也不会用太多的时间来删除。
最后，稍稍总结下，对于大个的集合对象，放redis的时候需要额外注意，如果想依赖redis的过期，可能会造成过期时短暂的redis block。
所以，要善待redis数据，比如不用了就自己清理掉，不要等着redis来帮你
解决办法:
解决办法:
1:
登录redis :
redis-cli
127.0.0.1:6379>config set stop-writes-on-bgsave-error no
2:使用redis-cli修改rdb目录
CONFIG SET dir /tmp/redis_data
CONFIG SET dbfilename temp.rdb
重启redis-server，问题解决！但是需要每次启动server都要修改rdb的路径。
3:直接修改redis.conf文件
dir /tmp/redis_data #./ --> /tmp/redis_data
dbfilename temp.rdb #
启动redis服务