[Docker應用系列·1]淺析JedisPool

本文環境：
jedis 2.1.0

redis 2.8.13

Redis無響應

我們的各個子系統均使用Jedis作為Redis的Java Client讀寫資料。

Jedis底層使用Apache的Common Pool，每個Jedis物件在底層都視為一個Object。

當釋放連線失敗後，我們的做法只是輸出錯誤日誌，這會導致該連線無法回收再利用，最終伺服器的連線池會被拖垮，現象就是我們遇到的無響應、重啟就好。

此前我們分析過，現在得出的結論是：這不是伺服器作業系統連線數的問題，也不是資料頻繁讀寫的問題，而是釋放資源時遇到異常時，我們沒有將該連線直接斷掉、丟棄。

如下是AEnv程式碼的相關變更情況，僅做參考：

高效讀寫調研

常用的Jedis讀寫方式包括：set/get、hset/hget和mset/mget，分別用作基本讀寫、hash讀寫和批量讀寫。

對此，我進行了一次效能測試（見下圖）。

從結果上看，批量讀寫的優勢是非常明顯的，如果子系統有類似業務邏輯，希望考慮這種形式。對於hash讀寫，在資料量聚集在某個特殊範圍內時，其效率是比基本讀寫要高的。

另外，Jedis的單點是執行緒不安全的，通過Apache的Common Pool獲取的Jedis例項是執行緒安全的，因此不建議子系統使用new一個例項的方式。

Master-Slave調研

Redis的主從環境，我已經使用Docker搭建好，參見[[Docker系列·10] 搭建Redis伺服器](http://www.atatech.org/articles/21551)

本次調研的目的是：觀察主從複製、讀寫分離是否可以提高讀寫效率（雖然主從模式會提供高可用性，但目前子系統更關注的是速度）。

測試採用兩個Jedis執行緒池一主一輔，主寫、輔讀。

單執行緒的測試結果如讀寫效能並不高。

100個執行緒的測試情況如下。從圖中可以看出，資料量增到10000條的時候是個拐點，讀寫分離在此處開始呈現優勢。不管是否讀寫分離，單次SET永遠不是高效的寫入方式。
HSET在5萬條資料的單機讀寫時出現過讀超時，懷疑在做rehash（表中紅色條目）。

附：

Docker Redis示意圖：

![2014_08_27_redis_master_slave]
(http://img1.tbcdn.cn/L1/461/1/519d6d0663bda5dbd512829b3da221f1e0872743)