The integration of redis and spring is generally divided into spring-data-redis integration and jedis integration. Let’s first look at the difference between the two.
1. The referenced dependencies are different:
The dependencies used by spring-data-redis are as follows:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-redis</artifactId>
<version>1.8.9.RELEASE</version>
</dependency>The dependencies used by jedis are as follows:
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
<type>jar</type>
<scope>compile</scope>
</dependency>2. Differences in how to manage jedis instances and operate redis services:
spring-data-redis：
It is managed through org.springframework.data.redis.connection.jedis.JedisConnectionFactory, that is, through factory class management, and then operates the redis service through the configured template bean. , the code segment is filled with a large number of template fragment codes that have nothing to do with the business. The code is redundant and difficult to maintain. For example, the following code:
protected RedisTemplate<Serializable, Serializable> redisTemplate;
public void saveUser(User user) {
redisTemplate.execute(new RedisCallback<Object>() {
@Override
public Object doInRedis(RedisConnection connection) throws DataAccessException {
connection.set(redisTemplate.getStringSerializer().serialize("user.uid." + user.getId()),
redisTemplate.getStringSerializer().serialize(user.getName()));
return null;
}
});
}
public User getUser(long id) {
return redisTemplate.execute(new RedisCallback<User>() {
@Override
public User doInRedis(RedisConnection connection) throws DataAccessException {
byte[] key = redisTemplate.getStringSerializer().serialize("user.uid." + id);
if (connection.exists(key)) {
byte[] value = connection.get(key);
String name = redisTemplate.getStringSerializer().deserialize(value);
User user = new User();
user.setName(name);
user.setId(id);
return user;
}
return null;
}
});
}Introduction to RedisTemplate
spring encapsulates the RedisTemplate object for comparison Various operations of redis, it supports all redis native APIs. RedisTemplate provides the use of several commonly used interface methods, namely:
private ValueOperationsb56561a2c0bc639cf0044c0859afb88f valueOps; private ListOperationsb56561a2c0bc639cf0044c0859afb88f listOps;private SetOperationsb56561a2c0bc639cf0044c0859afb88f setOps; private ZSetOperationsb56561a2c0bc639cf0044c0859afb88f zSetOps;
RedisTemplate defines five data structure operations
redisTemplate.opsForValue();//操作字符串 redisTemplate.opsForHash();//操作hash redisTemplate.opsForList();//操作list redisTemplate.opsForSet();//操作set redisTemplate.opsForZSet();//操作有序set StringRedisTemplate与RedisTemplate
The relationship between the two is that StringRedisTemplate inherits RedisTemplate.
The data between the two is not common; that is to say, StringRedisTemplate can only manage the data in StringRedisTemplate, and RedisTemplate can only manage the data in RedisTemplate.
There are two serialization strategies adopted by SDR by default, one is the serialization strategy of String and the other is the serialization strategy of JDK.
StringRedisTemplate uses the String serialization strategy by default, and the saved keys and values are serialized and saved using this strategy.
RedisTemplate uses the JDK serialization strategy by default, and the saved keys and values are serialized and saved using this strategy.
jedis method:
Managed through redis.clients.jedis.JedisPool, that is, managed through the pool, obtain the jedis instance through the pool object, and then directly operate the redis service through the jedis instance, eliminating Redundant code that has nothing to do with the business, such as the following code snippet:
private JedisPool jedisPool;
public String save(String key,String val) {
Jedis jedis = jedisPool.getResource();
return jedis.set(key, val);
}The change from factory class to pool is equivalent to the change in the way mybatis connects to mysql. The code becomes simpler and easier to maintain. It's easier. Jedis uses apache commons-pool2 to manage the Jedis resource pool, so a very important parameter when defining JedisPool is the resource pool GenericObjectPoolConfig. The usage method is as follows, which has many parameters for resource management and use.
Parameter description
JedisPool ensures that resources are within a controllable range and provides thread safety, but a reasonable GenericObjectPoolConfig configuration can protect applications using Redis. Here are some of its details Important parameters are explained and suggested:
In the current environment, the Jedis connection is the resource, and the JedisPool manages the Jedis connection.
1. Resource settings and usage
maxTotal: the maximum number of connections in the resource pool; default value: 8 See the next section for setting suggestions
maxIdle: the maximum number of idle connections allowed in the resource pool; Default value: 8; Usage recommendations: See the next section for setting recommendations
minIdle: The resource pool ensures the minimum number of idle connections; Default value: 0; Usage recommendations: See the next section for setting recommendations
blockWhenExhausted: When the resource pool is exhausted After that, whether the caller wants to wait. Only when true, the following maxWaitMillis will take effect; Default value: true; Usage recommendations: It is recommended to use the default value
maxWaitMillis: When the resource pool connection is exhausted, the caller's maximum waiting time (in milliseconds) - 1: Indicates never timeout; Usage recommendations: It is not recommended to use the default value
testOnBorrow: Whether to perform connection validity detection (ping) when borrowing a connection from the resource pool, invalid connections will be removed; Default value: false; Usage recommendations : When the business volume is large, it is recommended to set it to false (the cost of one more ping).
testOnReturn: Whether to perform connection validity detection (ping) when returning the connection to the resource pool, invalid connections will be removed; Default value: false; Usage recommendations: When the business volume is large, it is recommended to set it to false (one more ping overhead).
jmxEnabled: Whether to enable jmx monitoring, which can be used for monitoring; Default value: true; Usage recommendations: It is recommended to enable it, but the application itself must also be enabled
2. Idle resource monitoring
Idle Jedis Object detection is completed by a combination of the following four parameters. testWhileIdle is the switch of this function.
testWhileIdle: Whether to enable idle resource monitoring; Default value: false; Usage suggestions: true
timeBetweenEvictionRunsMillis: Detection period of idle resources (unit: milliseconds); Default value: -1: No detection; Usage suggestions: Recommended settings , choose the period by yourself, you can also use the default or use the configuration in JedisPoolConfig below
minEvictableIdleTimeMillis: the minimum idle time of resources in the resource pool (unit: milliseconds), after reaching this value, idle resources will be removed; default value: 1000 60 30 = 30 minutes; Usage suggestions: You can decide according to your own business. Most of the default values are sufficient. You can also consider using the configuration in JeidsPoolConfig below
numTestsPerEvictionRun: The number of samples per time when detecting idle resources; default value: 3; Usage suggestions: You can fine-tune according to the number of your own application connections. If set to -1, all connections will be monitored for idleness
For more Redis related knowledge, please visit Redis usage tutorial Column!
The above is the detailed content of What is the difference between redis and jedis. For more information, please follow other related articles on the PHP Chinese website!