Was ist der Unterschied zwischen Redis und Jedis?

Die Integration von Redis und Spring ist im Allgemeinen in Spring-Data-Redis-Integration und Jedis-Integration unterteilt.

1 Referenzabhängigkeiten sind unterschiedlich:

Die von spring-data-redis verwendeten Abhängigkeiten sind wie folgt:

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

Die von jedis verwendeten Abhängigkeiten sind wie folgt:

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

2 in der Art und Weise, Jedis-Instanzen zu verwalten und Redis-Dienste zu betreiben:

spring-data-redis:

Es wird also über org.springframework.data.redis.connection.jedis.JedisConnectionFactory verwaltet Durch die Verwaltung der Factory-Klasse und dann durch die konfigurierte Template-Bean zum Betreiben des Redis-Dienstes wird das Codesegment mit einer großen Anzahl von Template-Fragmentcodes gefüllt, die nichts mit dem Geschäft zu tun haben. Der Code ist redundant und schwer zu warten. Zum Beispiel der folgende 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;
        }
    });
}

Einführung in RedisTemplate

Spring kapselt das RedisTemplate-Objekt zum Vergleich. Verschiedene Vorgänge von Redis, es unterstützt alle nativen Redis-APIs. RedisTemplate bietet die Verwendung mehrerer häufig verwendeter Schnittstellenmethoden, nämlich:

private ValueOperations private SetOperations zSetOps;

RedisTemplate definiert fünf Datenstrukturoperationen

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

Die Beziehung zwischen den beiden besteht darin, dass StringRedisTemplate RedisTemplate erbt.
Die Daten zwischen den beiden sind nicht identisch. Das heißt, StringRedisTemplate kann nur die Daten in StringRedisTemplate verwalten, und RedisTemplate kann nur die Daten in RedisTemplate verwalten.
SDR verwendet standardmäßig zwei Serialisierungsstrategien: eine ist die Serialisierungsstrategie von String und die andere ist die Serialisierungsstrategie von JDK.
StringRedisTemplate verwendet standardmäßig die String-Serialisierungsstrategie, und die gespeicherten Schlüssel und Werte werden mit dieser Strategie serialisiert und gespeichert.

RedisTemplate verwendet standardmäßig die JDK-Serialisierungsstrategie, und die gespeicherten Schlüssel und Werte werden mit dieser Strategie serialisiert und gespeichert.

Jedis-Methode:

Verwaltet über redis.clients.jedis.JedisPool, dh über den Pool verwaltet, die Jedis-Instanz über das Poolobjekt abgerufen und dann den Redis-Dienst direkt betrieben die jedis-Instanz, wodurch redundanter Code eliminiert wird, der nichts mit dem Geschäft zu tun hat, wie zum Beispiel das folgende Code-Snippet:

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

Der Wechsel von der Factory-Klasse zum Pool entspricht der Änderung in der Verbindung von mybatis mit MySQL wird einfacher und leichter zu warten. Jedis verwendet Apache Commons-Pool2, um den Jedis-Ressourcenpool zu verwalten. Daher ist der Ressourcenpool GenericObjectPoolConfig ein sehr wichtiger Parameter, der viele Parameter für die Ressourcenverwaltung und -nutzung enthält.

Parameterbeschreibung

JedisPool stellt sicher, dass die Ressourcen innerhalb eines kontrollierbaren Bereichs liegen und sorgt für Thread-Sicherheit, aber eine angemessene GenericObjectPoolConfig-Konfiguration kann Anwendungen mit Redis schützen. Hier werden einige seiner wichtigen Parameter erläutert vorgeschlagen:

In der aktuellen Umgebung sind Jedis-Verbindungen Ressourcen und JedisPool verwaltet Jedis-Verbindungen.

1. Ressourceneinstellungen und -nutzung

maxTotal: die maximale Anzahl von Verbindungen im Ressourcenpool; Standardwert: 8 Siehe den nächsten Abschnitt für Einstellungsempfehlungen
maxIdle: die maximale Anzahl von Vom Ressourcenpool zugelassene Leerlaufverbindungen; Standardwert: 8; Nutzungsempfehlungen: Siehe nächster Abschnitt.
minIdle: Der Ressourcenpool stellt die Mindestanzahl an Leerlaufverbindungen sicher Abschnitt für Einstellungsempfehlungen
blockWhenExhausted: Wenn der Ressourcenpool erschöpft ist. Danach, ob der Anrufer warten möchte. Nur wenn „true“ gilt, wird der folgende maxWaitMillis wirksam; 1: Gibt an, dass es nie zu einer Zeitüberschreitung kommt. Nutzungsempfehlungen: Es wird nicht empfohlen, den Standardwert zu verwenden.
testOnBorrow: Ob beim Ausleihen einer Verbindung aus dem Ressourcenpool eine Verbindungsgültigkeitserkennung (Ping) durchgeführt werden soll. Standardwert: false; Nutzungsempfehlungen: Wenn das Geschäftsvolumen groß ist, wird empfohlen, es auf false zu setzen (die Kosten für einen weiteren Ping).
testOnReturn: Gibt an, ob beim Zurückgeben der Verbindung zum Ressourcenpool eine Verbindungsgültigkeitserkennung (Ping) durchgeführt werden soll. Standardwert: false. Verwendungsempfehlungen: Wenn das Geschäftsvolumen groß ist, wird empfohlen, dies festzulegen auf false (ein weiterer Ping-Overhead).
jmxEnabled: Ob die JMX-Überwachung aktiviert werden soll, die für die Überwachung verwendet werden kann; Verwendungsempfehlungen: Es wird empfohlen, sie zu aktivieren, aber die Anwendung selbst muss auch aktiviert sein

testWhileIdle: Ob die Überwachung inaktiver Ressourcen aktiviert werden soll; Standardwert: false; Verwendungsvorschläge: true
timeBetweenEvictionRunsMillis: Erkennungszeitraum von inaktiven Ressourcen (in Millisekunden); , wählen Sie den Zeitraum selbst aus, Sie können auch die Standardeinstellung verwenden oder die Konfiguration in JedisPoolConfig unten verwenden
minEvictableIdleTimeMillis: die minimale Leerlaufzeit der Ressourcen im Ressourcenpool (Einheit: Millisekunden), nach Erreichen dieses Werts die inaktiven Ressourcen wird entfernt; Standardwert: 1000 60 30 = 30 Minuten; Verwendungsvorschläge: Sie können je nach Ihrem Unternehmen entscheiden, die meisten Standardwerte reichen aus, Sie können auch die Konfiguration in JeidsPoolConfig unten verwenden
numTestsPerEvictionRun : die Anzahl der Stichproben pro Zeit beim Erkennen inaktiver Ressourcen; Standardwert: 3; Verwendungsvorschläge: Sie können eine Feinabstimmung entsprechend der Anzahl der Verbindungen in Ihrer eigenen Anwendung vornehmen. Bei Einstellung auf -1 werden alle Verbindungen im Leerlauf überwacht >

Tutorial zur Redis-Nutzung!

Das obige ist der detaillierte Inhalt vonWas ist der Unterschied zwischen Redis und Jedis?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!