1、DB端連接數過大的問題
在服務器端我們經常可以看到db上存在大量的tcp連接，而通過ss或者netstat命令查看，發現大量的連接處於established狀態。
進一步通過redis的client list命令發現，很多連接的idle時間都很大，這意味着很多連接長時間沒有活動和傳出數據。
服務器端維持很大的連接數，一方面需要消耗很多的進程資源，對於單進程的redis或者twemproxy，需要占用進程的調度時間；
另外，過多的空閑連接數對於db的容量評估也帶來錯誤性的判斷。
2、redis/twemproxy和mc的connection timeout
目前在服務器端都沒有設置任何連接超時的參數，不用擔心服務器端主動斷開連接。
因而需要客戶端程序主動的釋放不再使用的連接和連接池中長時間空閑的連接。
3、redis/mc最大連接數
redis配置中最大允許1w個連接。
mc配置中最大允許接受65535個連接。
當應用程序中的並發連接數超過redis/mc服務器端的允許的連接數時，對redis/mc進行擴容為最佳方案，保證db能夠提供高性能服務。
4、客戶端連接池的配置要點。
1） 連接池的大小。單個應用程序中，接口的並發的連接數的1.5倍足夠滿足需求。
2） 保持一定的空閑連接數，這樣可以保證客戶端可快速的獲取連接對象。
3） 合理設置空閑接的回收時間。避免客戶端維持大量的空閑連接。
4） 定時檢查長連接對象的有效性。主要是防止網絡抖動或者db端出現異常時主動關閉連接。
5、JedisPool Config推薦的設置。
jedipool連接池配置推薦的設置 適合v2.5+版本： // 設置最大連接數，（根據並發請求合理設置）。 config.setMaxTotal(100); // 多長空閑時間之后回收空閑連接 setMinEvictableIdleTimeMillis(60000); // 設置最小空閑連接數或者說初始化連接數 （建議和最大空閑連接數相同） config.setMinIdle(20); // 設置最大空閑連接數（根據並發請求合理設置） config.setMaxIdle(20); // 設置最大等待時間 （根據業務需求調整） config.setMaxWaitMillis(3000); // 跟驗證有關 config.setTestOnBorrow(true); // 跟驗證有關 config.setTestOnReturn(false); // 啟動空閑連接的測試 config.setTestWhileIdle(false);