本文環境： jedis 2.1.0
redis 2.8.13
我們的各個子系統均使用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一個執行個體的方式。
本次調研的目的是：觀察主從複制、讀寫分離是否可以提高讀寫效率（雖然主從模式會提供高可用性，但目前子系統更關注的是速度）。
測試采用兩個jedis線程池一主一輔，主寫、輔讀。
單線程的測試結果如讀寫性能并不高。
100個線程的測試情況如下。從圖中可以看出，資料量增到10000條的時候是個拐點，讀寫分離在此處開始呈現優勢。不管是否讀寫分離，單次set永遠不是高效的寫入方式。
hset在5萬條資料的單機讀寫時出現過讀逾時，懷疑在做rehash（表中紅色條目）。
附：
docker redis示意圖：
![2014_08_27_redis_master_slave]