轉載：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服務
沒有設置外網鏈接，服務器訪問服務器地址沒有設置127.0.0.1
https://blog.csdn.net/qq_21583077/article/details/88225728