針對redis連接池獲取連接出現長時間等待問題雖然現在通過調整線程池大小和去掉調用是否聯通號碼邏輯暫時起到了一些作用，但是
卻是治標不治本的方案。因此秉着事情必須要有閉環的宗旨。今天花了一天時間做了如下的壓力測測試。
知識儲備：
jedis客戶端連接方式是基於tcp的阻塞式連接方式。
lettuce客戶端連接方式是基於netty的多路複用異步非阻塞的連接方案。（目前業界解決高併發大數據的問題的思路）
在場景一：
最大線程數：10 最大空閒線程10 最小空閒線程5 併發數 100/s 時間 120s
jedis客戶端連接
lettuce客戶端連接
在場景二：
最大線程數：10 最大空閒線程10 最小空閒線程5 併發數 200/s 時間 120s
jedis客戶端連接
lettuce客戶端連接
在場景三：
最大線程數：50 最大空閒線程50 最小空閒線程50 併發數 200/s 時間 120s
jedis客戶端連接
lettuce客戶端連接
在場景四：
最大線程數：70 最大空閒線程50 最小空閒線程20 併發數 200/s 時間 120s
jedis客戶端連接
lettuce客戶端連接
結論1：
所有場景：
jedis表現的吞吐量優於lettuce連接方案。
lettuce表現的響應時間和穩定性優於jedis連接方案。
結論2：
場景一 vs 場景二
通過增大併發量
jedis吞吐量增大，超時錯誤開始出現，最大響應時間增大。
原因分析：連接數達到最大值，出現連接超時拒絕，連接等待出現 。所以最大耗時增加。
lettuce表現都是毫秒級別，但是平均耗時和最大耗時開始增加。
原因分析：lettuce採用多路複用原理，因此真正工作的連接受制於CPU核數因此增大連接數反而增加了線程上下文切換時間。因此建議調整爲 CPU覈實+1.
場景二 vs 場景三、四
通過調大線程池數量
jedis吞吐量增大，超時錯誤開始出現，最大響應時間增大。
原因分析：連接數達到最大值，出現連接超時拒絕，連接等待出現 。所以最大耗時增加。
lettuce表現都是毫秒級別，但是平均耗時和最大耗時開始增加。
原因分析：lettuce採用多路複用原理，因此真正工作的連接受制於CPU核數因此增大連接數反而增加了線程上下文切換時間。因此建議調整爲 CPU核數+1.
最終結論：
調大連接池大小能夠提高jedis的吞吐量，但是不能避免出現超時錯誤和長時間等待。
jedis連接方式最大連接數和最小、最大空閒連接數設置爲一樣有利於減少上下文切換時間，提升效率。
letturce調大連接池大小反而會影響性能，最佳個數= CPU核數+1.
letturce整體穩定性和性能由於jedis方式。