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，因爲寫內存基本上沒有問題（這個涉及到一致性，高併發場景有點複雜）。