redis是一種單線程機制的nosql數(shù)據(jù)庫，基于key-value，數(shù)據(jù)可持久化落盤。由于單線程所以redis本身并沒有鎖的概念，多個客戶端連接并不存在競爭關(guān)系，但是利用jedis等客戶端對redis進(jìn)行并發(fā)訪問時會出現(xiàn)問題。發(fā)生連接超時、數(shù)據(jù)轉(zhuǎn)換錯誤、阻塞、客戶端關(guān)閉連接等問題，這些問題均是由于客戶端連接混亂造成。

同時，單線程的天性決定，高并發(fā)對同一個鍵的操作會排隊處理，如果并發(fā)量很大，可能造成后來的請求超時。

在遠(yuǎn)程訪問redis的時候，因為網(wǎng)絡(luò)等原因造成高并發(fā)訪問延遲返回的問題。

解決辦法

1.在客戶端將連接進(jìn)行池化，同時對客戶端讀寫Redis操作采用內(nèi)部鎖synchronized。

2.服務(wù)器角度，利用setnx變向?qū)崿F(xiàn)鎖機制。這個方法在實際環(huán)境中如何使用，本人并不清楚。

Redis常見錯誤分析

異常代碼1：

redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool

問題分析：redis.clients.util.Pool.getResource會從JedisPool池中返回一個可用的redis連接，關(guān)于JedisPool中可用連接的配置有幾個重要的參數(shù)如下：

1.MaxActive：可用連接實例的最大數(shù)目，為負(fù)數(shù)的時候沒有限制。

2.MaxIdle:空閑連接實例的最大數(shù)目，為負(fù)值時沒有限制。

3.MaxWait：等待獲取鏈接的超時時間。

也就是說當(dāng)連接池中沒有active/idle的連接時，會等待maxWait時間，如果等待超時還沒有可用連接，則拋出Could not get a resource from the pool異常。所以為避免這樣的錯誤，

我們應(yīng)該根據(jù)程序?qū)嶋H情況合理設(shè)置這三個參數(shù)的值，同時在我們獲取一個連接的程序方法中也應(yīng)該合理的處理這個異常，當(dāng)沒有連接可用時，等待一段時間再獲取也許是個比較好的選擇。

異常代碼2：

redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out

遇到這個異常，可能會比較疑惑，redis是對內(nèi)存的操作，速度一個在毫秒級別，在對redis操作出現(xiàn)秒級別的操作時會讓人感覺疑惑，但是本文開頭已經(jīng)說過了，在一些特殊情況下，redis出現(xiàn)超時并不奇怪。jedis在初始化JedisPool時應(yīng)該根據(jù)實際情況通過redis.clients.jedis.JedisPoolConfig合理設(shè)置連接池參數(shù)，通過redisPool構(gòu)造方法，設(shè)置socket讀取輸入InputStream的超時時間。

`pool = new JedisPool(config, host, port, 100000)`;

第四個參數(shù)是time out，單位是毫秒。可以通過合理的設(shè)置這個值來規(guī)避問題。但是這不能完全解決超時的為題。有些高并發(fā)情況下，延時返回時間甚至?xí)_(dá)到幾十秒的極端情況。這個問題要通過代碼層面解決redis單線程本身不支持鎖，在對同一個鍵進(jìn)行并發(fā)操作會產(chǎn)生競爭的問題。