背景
合理的JedisPool資源池參數設置能為業務使用Redis保駕護航，本文將對JedisPool的使用、資源池的參數進行詳細說明，最后給出“最合理”配置。
一、使用方法
以官方的2.9.0為例子(Jedis Release)，Maven依賴如下：
|
1
2
3
4
5
6
|
<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>2.9.0</version> <scope>compile</scope></dependency> |
Jedis使用apache commons-pool2對Jedis資源池進行管理，所以在定義JedisPool時一個很重要的參數就是資源池GenericObjectPoolConfig，使用方式如下，其中有很多資源管理和使用的參數(具體看第二節)
注意：后面會提到建議用JedisPoolConfig代替GenericObjectPoolConfig
|
1
2
3
4
5
|
GenericObjectPoolConfig jedisPoolConfig = new GenericObjectPoolConfig();jedisPoolConfig.setMaxTotal(..);jedisPoolConfig.setMaxIdle(..);jedisPoolConfig.setMinIdle(..);jedisPoolConfig.setMaxWaitMillis(..); |
JedisPool的初始化如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
// redisHost和redisPort是實例的IP和端口// redisPassword是實例的密碼// timeout，這里既是連接超時又是讀寫超時，從Jedis 2.8開始有區分connectionTimeout和soTimeout的構造函數JedisPool jedisPool = new JedisPool(jedisPoolConfig, redisHost, redisPort, timeout, redisPassword);Jedis jedis = null;try { jedis = jedisPool.getResource(); //具體的命令 jedis.executeCommand()} catch (Exception e) { logger.error(e.getMessage(), e);} finally { if (jedis != null) jedis.close(); //注意這里不是關閉連接，在JedisPool模式下，Jedis會被歸還給資源池。} |
二、參數說明
JedisPool保證資源在一個可控范圍內，并且提供了線程安全，但是一個合理的GenericObjectPoolConfig配置能為應用使用Redis保駕護航，下面將對它的一些重要參數進行說明和建議：
在當前環境下，Jedis連接就是資源，JedisPool管理的就是Jedis連接。
1. 資源設置和使用
| 序號 | 參數名 | 含義 | 默認值 | 使用建議 |
|---|---|---|---|---|
| 1 | maxTotal | 資源池中最大連接數 | 8 | 設置建議見下節 |
| 2 | maxIdle | 資源池允許最大空閑的連接數 | 8 | 設置建議見下節 |
| 3 | minIdle | 資源池確保最少空閑的連接數 | 0 | 設置建議見下節 |
| 4 | blockWhenExhausted | 當資源池用盡后，調用者是否要等待。只有當為true時，下面的maxWaitMillis才會生效 | true | 建議使用默認值 |
| 5 | maxWaitMillis | 當資源池連接用盡后，調用者的最大等待時間(單位為毫秒) | -1：表示永不超時 | 不建議使用默認值 |
| 6 | testOnBorrow | 向資源池借用連接時是否做連接有效性檢測(ping)，無效連接會被移除 | false | 業務量很大時候建議設置為false(多一次ping的開銷)。 |
| 7 | testOnReturn | 向資源池歸還連接時是否做連接有效性檢測(ping)，無效連接會被移除 | false | 業務量很大時候建議設置為false(多一次ping的開銷)。 |
| 8 | jmxEnabled | 是否開啟jmx監控，可用于監控 | true | 建議開啟，但應用本身也要開啟 |
2.空閑資源監測
空閑Jedis對象檢測，下面四個參數組合來完成，testWhileIdle是該功能的開關。
| 序號 | 參數名 | 含義 | 默認值 | 使用建議 |
|---|---|---|---|---|
| 1 | testWhileIdle | 是否開啟空閑資源監測 | false | true |
| 2 | timeBetweenEvictionRunsMillis | 空閑資源的檢測周期(單位為毫秒) | -1：不檢測 | 建議設置，周期自行選擇，也可以默認也可以使用下面JedisPoolConfig中的配置 |
| 3 | minEvictableIdleTimeMillis | 資源池中資源最小空閑時間(單位為毫秒)，達到此值后空閑資源將被移除 | 1000 60 30 = 30分鐘 | 可根據自身業務決定，大部分默認值即可，也可以考慮使用下面JeidsPoolConfig中的配置 |
| 4 | numTestsPerEvictionRun | 做空閑資源檢測時，每次的采樣數 | 3 | 可根據自身應用連接數進行微調,如果設置為-1，就是對所有連接做空閑監測 |
為了方便使用，Jedis提供了JedisPoolConfig，它本身繼承了GenericObjectPoolConfig設置了一些空閑監測設置
|
1
2
3
4
5
6
7
8
9
10
11
|
public class JedisPoolConfig extends GenericObjectPoolConfig { public JedisPoolConfig() { // defaults to make your life with connection pool easier :) setTestWhileIdle(true); // setMinEvictableIdleTimeMillis(60000); // setTimeBetweenEvictionRunsMillis(30000); setNumTestsPerEvictionRun(-1); }} |
所有默認值可以從org.apache.commons.pool2.impl.BaseObjectPoolConfig中看到。
三、資源池大小(maxTotal)、空閑(maxIdle minIdle)設置建議
1.maxTotal：最大連接數
實際上這個是一個很難回答的問題，考慮的因素比較多：
- 業務希望Redis并發量
- 客戶端執行命令時間
- Redis資源：例如 nodes(例如應用個數) * maxTotal 是不能超過redis的最大連接數。
- 資源開銷：例如雖然希望控制空閑連接，但是不希望因為連接池的頻繁釋放創建連接造成不必靠開銷。
以一個例子說明，假設:
- 一次命令時間（borrow|return resource + Jedis執行命令(含網絡) ）的平均耗時約為1ms，一個連接的QPS大約是1000
- 業務期望的QPS是50000
那么理論上需要的資源池大小是50000 / 1000 = 50個。但事實上這是個理論值，還要考慮到要比理論值預留一些資源，通常來講maxTotal可以比理論值大一些。
但這個值不是越大越好，一方面連接太多占用客戶端和服務端資源，另一方面對于Redis這種高QPS的服務器，一個大命令的阻塞即使設置再大資源池仍然會無濟于事。
2. maxIdle minIdle
maxIdle實際上才是業務需要的最大連接數，maxTotal是為了給出余量，所以maxIdle不要設置過小，否則會有new Jedis(新連接)開銷，而minIdle是為了控制空閑資源監測。
連接池的最佳性能是maxTotal = maxIdle ,這樣就避免連接池伸縮帶來的性能干擾。但是如果并發量不大或者maxTotal設置過高，會導致不必要的連接資源浪費。
可以根據實際總OPS和調用redis客戶端的規模整體評估每個節點所使用的連接池。
3.監控
實際上最靠譜的值是通過監控來得到“最佳值”的，可以考慮通過一些手段(例如jmx)實現監控，找到合理值。
四、常見問題
1.資源“不足"
|
1
2
3
4
|
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool…Caused by: java.util.NoSuchElementException: Timeout waiting for idle objectat org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449) |
或者
|
1
2
3
4
|
redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool…Caused by: java.util.NoSuchElementException: Pool exhaustedat org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464) |
兩種情況均屬于無法從資源池獲取到資源，但第一種是超時，第二種是因為blockWhenExhausted為false根本就不等。
遇到此類異常，不要盲目的認為資源池不夠大，第三節已經進行了分析。具體原因可以排查：網絡、資源池參數設置、資源池監控(如果對jmx監控)、代碼(例如沒執行jedis.close())、慢查詢、DNS等問題。
具體可以參考該文章：https://www.atatech.org/articles/77799
2. 預熱JedisPool
由于一些原因(例如超時時間設置較小原因)，有的項目在啟動成功后會出現超時。JedisPool定義最大資源數、最小空閑資源數時，不會真的把Jedis連接放到池子里，第一次使用時，池子沒有資源使用，會new Jedis，使用后放到池子里，可能會有一定的時間開銷，所以也可以考慮在JedisPool定義后，為JedisPool提前進行預熱，例如以最小空閑數量為預熱數量
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
List<Jedis> minIdleJedisList = new ArrayList<Jedis>(jedisPoolConfig.getMinIdle());for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) { Jedis jedis = null; try { jedis = pool.getResource(); minIdleJedisList.add(jedis); jedis.ping(); } catch (Exception e) { logger.error(e.getMessage(), e); } finally { }}for (int i = 0; i < jedisPoolConfig.getMinIdle(); i++) { Jedis jedis = null; try { jedis = minIdleJedisList.get(i); jedis.close(); } catch (Exception e) { logger.error(e.getMessage(), e); } finally { }} |
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://www.cnblogs.com/benwu/articles/8616141.html
