Quelle est la différence entre Redis et Jedis

L'intégration de redis et spring est généralement divisée en intégration spring-data-redis et intégration jedis. Examinons d'abord la différence entre les deux

1. les dépendances de référence sont différentes :

Les dépendances utilisées par spring-data-redis sont les suivantes :

<dependency>  
      <groupId>org.springframework.data</groupId>  
      <artifactId>spring-data-redis</artifactId>  
      <version>1.8.9.RELEASE</version>  
</dependency>

Les dépendances utilisées par jedis sont les suivantes :

<dependency>
       <groupId>redis.clients</groupId>
       <artifactId>jedis</artifactId>
       <version>2.9.0</version>
       <type>jar</type>
       <scope>compile</scope>
</dependency>

2. dans la manière de gérer les instances jedis et d'exploiter les services redis :

spring-data-redis :

Il est géré via org.springframework.data.redis.connection.jedis.JedisConnectionFactory, c'est-à-dire , via la gestion des classes d'usine, puis via le bean modèle configuré pour faire fonctionner le service redis , le segment de code est rempli d'un grand nombre de codes de fragments de modèle qui n'ont rien à voir avec l'entreprise. Le code est redondant et difficile à maintenir. tel que le code suivant :

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 à RedisTemplate

spring encapsule l'objet RedisTemplate à des fins de comparaison. Diverses opérations de Redis, il prend en charge toutes les API natives Redis. RedisTemplate permet d'utiliser plusieurs méthodes d'interface couramment utilisées, à savoir :

private ValueOperationsb56561a2c0bc639cf0044c0859afb88f private ListOperationsb56561a2c0bc639cf0044c0859afb88f private SetOperationsb56561a2c0bc639cf0044c0859afb88f , V> zSetOps;

RedisTemplate définit cinq opérations de structure de données

redisTemplate.opsForValue();//操作字符串
redisTemplate.opsForHash();//操作hash
redisTemplate.opsForList();//操作list
redisTemplate.opsForSet();//操作set
redisTemplate.opsForZSet();//操作有序set
StringRedisTemplate与RedisTemplate

La relation entre les deux est que StringRedisTemplate hérite de RedisTemplate.
Les données entre les deux ne sont pas communes ; c'est-à-dire que StringRedisTemplate ne peut gérer que les données dans StringRedisTemplate, et RedisTemplate ne peut gérer que les données dans RedisTemplate.
Il existe deux stratégies de sérialisation adoptées par SDR par défaut, l'une est la stratégie de sérialisation String et l'autre est la stratégie de sérialisation JDK.
StringRedisTemplate utilise la stratégie de sérialisation String par défaut, et les clés et valeurs enregistrées sont sérialisées et enregistrées à l'aide de cette stratégie.

RedisTemplate utilise la stratégie de sérialisation JDK par défaut, et les clés et valeurs enregistrées sont sérialisées et enregistrées à l'aide de cette stratégie.

Méthode jedis :

Gérée via redis.clients.jedis.JedisPool, c'est-à-dire gérée via le pool, obtenue l'instance jedis via l'objet pool, puis exploitée directement le service redis via l'instance jedis, éliminant le code redondant qui n'a rien à voir avec l'entreprise, comme l'extrait de code suivant :

private JedisPool jedisPool;
public String save(String key,String val) {
Jedis jedis = jedisPool.getResource();
return jedis.set(key, val);
}

Le passage de la classe d'usine au pool est équivalent au changement de mybatis se connectant à mysql Le code. devient plus simple et plus facile à entretenir. Jedis utilise Apache commons-pool2 pour gérer le pool de ressources Jedis, donc un paramètre très important lors de la définition de JedisPool est le pool de ressources GenericObjectPoolConfig. La méthode d'utilisation est la suivante, qui comporte de nombreux paramètres pour la gestion et l'utilisation des ressources.

Description des paramètres

JedisPool garantit que les ressources se trouvent dans une plage contrôlable et assure la sécurité des threads, mais une configuration GenericObjectPoolConfig raisonnable peut protéger les applications utilisant Redis. Voici quelques-uns de ses détails. Les paramètres importants sont expliqués et. suggéré :

Dans l'environnement actuel, les connexions Jedis sont des ressources, et JedisPool gère les connexions Jedis.

1. Paramètres et utilisation des ressources

maxTotal : le nombre maximum de connexions dans le pool de ressources ; valeur par défaut : 8 Voir la section suivante pour les recommandations de configuration
maxIdle : le nombre maximum de connexions inactives autorisées par le pool de ressources ; Valeur par défaut : 8 ; Recommandations d'utilisation : voir la section suivante pour définir les recommandations
minIdle : Le pool de ressources garantit le nombre minimum de connexions inactives : 0 ; section pour définir les recommandations
blockWhenExhausted : lorsque le pool de ressources est épuisé Après cela, si l'appelant souhaite attendre. Uniquement lorsque vrai, le maxWaitMillis suivant prendra effet ; Valeur par défaut : true ; Il est recommandé d'utiliser la valeur par défaut
maxWaitMillis : lorsque la connexion au pool de ressources est épuisée, le temps d'attente maximum de l'appelant (en millisecondes) - 1 : Indique qu'il n'y a jamais d'expiration ; Recommandations d'utilisation : Il n'est pas recommandé d'utiliser la valeur par défaut
testOnBorrow : S'il faut effectuer une détection de validité de connexion (ping) lors de l'emprunt d'une connexion au pool de ressources, les connexions invalides seront supprimées ; false; Recommandations d'utilisation : Lorsque le volume d'affaires est important, il est recommandé de le définir sur false (le coût d'un ping supplémentaire).
testOnReturn : s'il faut effectuer une détection de validité de connexion (ping) lors du renvoi de la connexion au pool de ressources, les connexions non valides seront supprimées ; Valeur par défaut : false Recommandations d'utilisation : Lorsque le volume d'activité est important, il est recommandé de le définir ; à false (un ping supplémentaire).
jmxEnabled : s'il faut activer la surveillance jmx, qui peut être utilisée pour la surveillance ; Valeur par défaut : true ; Recommandations d'utilisation : Il est recommandé de l'activer, mais l'application elle-même doit également être activée

2. surveillance des ressources

La détection des objets Idle Jedis est complétée par une combinaison des quatre paramètres suivants testWhileIdle est le commutateur de cette fonction.

testWhileIdle : s'il faut activer la surveillance des ressources inactives ; Valeur par défaut : false ; Suggestions d'utilisation : true
timeBetweenEvictionRunsMillis : Période de détection des ressources inactives (en millisecondes) ; , choisissez la période par vous-même, vous pouvez également utiliser la valeur par défaut ou utiliser la configuration dans JedisPoolConfig ci-dessous
minEvictableIdleTimeMillis : le temps d'inactivité minimum des ressources dans le pool de ressources (unité : millisecondes), après avoir atteint cette valeur, les ressources inactives sera supprimé ; valeur par défaut : 1000 60 30 = 30 minutes ; Suggestions d'utilisation : Vous pouvez décider en fonction de votre propre entreprise, la plupart des valeurs par défaut sont suffisantes, vous pouvez également envisager d'utiliser la configuration dans JeidsPoolConfig ci-dessous
numTestsPerEvictionRun : le nombre d'échantillons par heure lors de la détection des ressources inactives ; valeur par défaut : 3 ; Suggestions d'utilisation : vous pouvez affiner en fonction du nombre de connexions dans votre propre application. Si la valeur est -1, toutes les connexions seront surveillées en inactivité

Pour plus de connaissances sur Redis, veuillez visiter la colonne

Tutoriel d'utilisation de Redis !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!