21 puntos que debes saber sobre el uso de Redis

Prefacio

Recientemente, estoy aprendiendo conocimientos relacionados con Redis y leí la especificación de desarrollo de Redis de Ali y el libro de desarrollo, operación y mantenimiento de Redis. Está dividido en cuatro direcciones: especificaciones de uso, comandos con boxes, operaciones reales del proyecto y configuración de operación y mantenimiento. He resuelto 21 puntos de atención al usar Redis. Espero que sea útil para todos. Aprendamos juntos.

Cuenta pública: El niño recogiendo caracoles

1. Especificación de uso de Redis

1.1, puntos clave de especificación

Cuando diseñamos claves de Redis, debemos prestar atención a los siguientes puntos:

Prefije el nombre de la empresa con la clave y sepárelo con dos puntos para evitar que se sobrescriban los conflictos de claves. Por ejemplo, en vivo: rango: 1

Para asegurarse de que la semántica de la clave sea clara, la longitud de la clave debe ser de menos de 30 caracteres tanto como sea posible.

La clave no debe contener caracteres especiales, como espacios, saltos de línea, comillas simples y dobles y otros caracteres de escape.

Las claves de Redis intentan configurar ttl para garantizar que las claves que no están en uso puedan limpiarse o eliminarse a tiempo.

1.2, los principales puntos de especificación de valor

El valor de Redis no se puede establecer arbitrariamente.

El primer punto es que si se almacenan una gran cantidad de bigKeys, habrá problemas que darán lugar a consultas lentas, crecimiento excesivo de la memoria, etc.

Si es un tipo de cadena, el tamaño de un solo valor se controla dentro de 10k.

Para los tipos hash, list, set, zset, el número de elementos generalmente no supera los 5000.

El segundo punto es seleccionar el tipo de datos apropiado. Muchos socios pequeños solo usan el tipo String de Redis, que viene con set y get. De hecho, Redis proporciona una gran cantidad de tipos de estructura de datos y algunos escenarios comerciales son más adecuados para hash、zsetesperar otros resultados de datos.

Contraejemplo:

set user:666:name jay
set user:666:age 18
复制代码

Ejemplo positivo

hmset user:666 name jay age 18 
复制代码

1.3. Establezca el tiempo de caducidad de la Clave, y preste atención a las claves de diferentes negocios, intente extender un poco el tiempo de caducidad

Porque los datos de Redis se almacenan en la memoria y los recursos de la memoria son muy valiosos.
Generalmente usamos Redis como caché, no como base de datos , por lo que el ciclo de vida de la clave no debería ser demasiado largo.
Por lo tanto, generalmente se recomienda que su clave use expirar para establecer el tiempo de expiración .

Si una gran cantidad de claves caduca en un momento determinado, Redis puede quedarse atascado o incluso cachear una avalancha cuando caduque, por lo que, en general, el tiempo de caducidad de las claves para diferentes negocios debe estar disperso. A veces, para el mismo negocio, también puede agregar un valor aleatorio al tiempo para extender el tiempo de vencimiento.

1.4. Se recomienda utilizar operaciones por lotes para mejorar la eficiencia.

Cuando escribimos SQL a diario, todos sabemos que las operaciones por lotes serán más eficientes. Actualizar 50 elementos a la vez es más eficiente que repetir 50 veces y actualizar un elemento cada vez. De hecho, los comandos de operación de Redis también son los mismos.

Un comando ejecutado por el cliente de Redis se puede dividir en 4 procesos: 1. Enviar comando -> 2. Cola de comandos -> 3. Ejecución de comando -> 4. Devolver resultado. 1 y 4 se denominan RRT (tiempo de ida y vuelta de ejecución de comandos). Redis proporciona comandos de operación por lotes, como mget, mset, etc., que pueden guardar RRT de manera efectiva. Sin embargo, la mayoría de los comandos no admiten operaciones por lotes, como hgetall y mhgetall no existe. Pipeline puede resolver este problema.

¿Qué es Pipeline? Puede ensamblar un conjunto de comandos de Redis, transmitirlos a Redis a través de un RTT y luego devolver los resultados de ejecución de este conjunto de comandos de Redis al cliente en orden.

Primero echemos un vistazo al modelo que ejecutó n comandos sin usar Pipeline:

Usando Pipeline para ejecutar n comandos, todo el proceso requiere 1 RTT, el modelo es el siguiente:

2. Los comandos con los que Redis tiene trampas

2.1. Atención `O(n)`complejidad del sistema, tales como `hgetall`, `smember`, `lrange`etc.

Porque Redis ejecuta comandos en un solo hilo. La complejidad temporal de los comandos como hgetall y smember es O (n). Cuando n continúa aumentando, la CPU de Redis seguirá aumentando y bloqueando la ejecución de otros comandos.

Los comandos como hgetall, smember e lrange no están necesariamente disponibles. Es necesario evaluar exhaustivamente la cantidad de datos, aclarar el valor de n y luego decidir. Por ejemplo, hgetall, si hay más elementos hash n, primero se puede usar hscan .

2.2 Utilice el comando de monitor de Redis con precaución

El comando Redis Monitor se usa para imprimir los comandos recibidos por el servidor Redis en tiempo real.Si queremos saber qué operaciones de comando ha realizado el cliente en el servidor Redis, podemos usar el comando Monitor para verlo, pero es generalmente se usa para depurar . Intente no usarlo en producción. Porque el comando de monitor puede hacer que la memoria de redis continúe elevándose.

El modelo de monitor es Jiangzi. Dará salida a todos los comandos ejecutados en el servidor de Redis. En términos generales, el QPS del servidor de Redis es muy alto, es decir, si se ejecuta el comando de monitor, el servidor de Redis está en el búfer de salida de el cliente Monitor. Habrá mucho "inventario", que ocupará mucha memoria de Redis.

2.3. El comando keys no se puede utilizar en el entorno de producción

El comando Redis Keys se utiliza para encontrar todas las claves que coinciden con un patrón determinado. Si desea verificar cuántas claves de un determinado tipo hay en Redis, muchos amigos piensan en usar el comando keys, de la siguiente manera:

keys key前缀*
复制代码

Sin embargo, redis keysatraviesa la coincidencia, y la complejidad es O（n）que cuantos más datos haya en la base de datos, más lento. Sabemos que redis es de un solo subproceso. Si hay muchos datos, la instrucción de claves hará que el subproceso de redis se bloquee y el servicio en línea también se pausará. El servicio no se reanudará hasta que se ejecute la instrucción. Por lo tanto, generalmente en un entorno de producción, no utilice el comando keys . El documento oficial también dice:

Advertencia: considere KEYS como un comando que solo debe usarse en entornos de producción con extremo cuidado. Puede arruinar el rendimiento cuando se ejecuta en grandes bases de datos. Este comando está destinado a operaciones de depuración y especiales, como cambiar el diseño del espacio de teclas. No utilice KEYS en su código de aplicación habitual. Si está buscando una forma de encontrar claves en un subconjunto de su espacio de claves, considere usar conjuntos.

De hecho, puede usar el comando de escaneo, que proporciona funciones de coincidencia de patrones como el comando de teclas. Su complejidad también es O (n), pero se realiza paso a paso a través del cursor, y no bloqueará el hilo de redis ; pero habrá una cierta probabilidad de repetición , y es necesario deduplicarlo una vez en el cliente .

El escaneo admite comandos iterativos incrementales, y los comandos iterativos incrementales también tienen desventajas: por ejemplo, el uso del comando SMEMBERS puede devolver todos los elementos contenidos actualmente en la clave establecida, pero para comandos iterativos incrementales como SCAN, porque en Durante la iteración incremental de las claves , las claves pueden modificarse, por lo que el comando de iteración incremental solo puede proporcionar garantías limitadas para los elementos devueltos.

2.4 Prohibir el uso de fluxhall, flushdb

El comando Flushall se usa para borrar los datos de todo el servidor Redis (eliminar todas las claves de todas las bases de datos).

El comando Flushdb se usa para borrar todas las claves en la base de datos actual.

Estos dos comandos son atómicos y no terminarán la ejecución. Una vez que comienza la ejecución, la ejecución no fallará.

2.5 Preste atención al uso del comando del

¿Qué comando suele utilizar para eliminar una clave? ¿Es una eliminación directa? Si elimina una clave, puede usar el comando del directamente. Pero, ¿ha pensado en la complejidad temporal de del? Discutámoslo por situación:

Si elimina una clave de tipo String, la complejidad del tiempo es O（1）, puede eliminar directamente .
Si elimina un tipo List / Hash / Set / ZSet, su complejidad es O(n), n representa el número de elementos.

Por lo tanto, si elimina una clave List / Hash / Set / ZSet, cuantos más elementos, más lento. Cuando n es muy grande, preste especial atención a él , que bloqueará el hilo principal. Entonces, si no se usa del, ¿cómo debemos eliminarlo?

Si es de tipo Lista, puede ejecutarlo lpop或者rpophasta que se eliminen todos los elementos.

Si es de tipo Hash / Set / ZSet, puede ejecutar la hscan/sscan/scanconsulta primero y luego ejecutar para hdel/srem/zremeliminar cada elemento a su vez.

2.6 Evite el uso de SORT, SINTER y otros comandos muy complejos.

La ejecución de comandos más complejos consumirá más recursos de la CPU y bloqueará el hilo principal. Por lo tanto, debe evitar ejecutar dichos SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTOREcomandos de agregación, generalmente se recomienda ponerlo en el lado del cliente para su ejecución.

3. Proyectar la operación real de combate y evitación de boxes

3.1 Puntos a tener en cuenta al utilizar bloqueos distribuidos

El candado distribuido es en realidad la realización de un candado que controla diferentes procesos de un sistema distribuido para acceder a los recursos compartidos juntos. Los candados distribuidos son necesarios para escenarios comerciales, como realizar pedidos con picos y agarrar sobres rojos. A menudo usamos Redis como un bloqueo distribuido, principalmente con estos puntos de atención:

3.1.1 Los dos comandos SETNX + EXPIRE se escriben por separado (un ejemplo típico de implementación de error)

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //释放锁
    }
}
复制代码

Si setnxse ejecuta el bloqueo y el tiempo de expiración está a punto de ejecutarse, el proceso se bloquea o debe reiniciarse para el mantenimiento, entonces el bloqueo será "inmortal" y otros subprocesos nunca podrán obtener el bloqueo , por lo que el general El bloqueo distribuido no puede ser así.

3.1.2 El valor de SETNX + es el tiempo de vencimiento (algunos socios pequeños implementan de esta manera, hay pits)

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}
复制代码

Desventajas de este esquema :

El tiempo de caducidad lo genera el propio cliente. En un entorno distribuido, el tiempo de cada cliente debe estar sincronizado

No existe una identificación única del titular, y otros clientes pueden liberarla o desbloquearla.

Cuando el bloqueo expira, varios clientes concurrentes los solicitan al mismo tiempo y todos se ejecutan jedis.getSet(). Al final, solo un cliente puede bloquear correctamente el bloqueo, pero otros clientes pueden sobrescribir el tiempo de vencimiento del bloqueo del cliente.

3.1.3: SET comando extendido (SET EX PX NX) (preste atención a posibles problemas)

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //释放锁
    }
}
复制代码

Es posible que todavía haya problemas con esta solución:

El bloqueo ha expirado y se ha liberado, y el negocio aún no se ha ejecutado.
Otro hilo borró el candado por error.

3.1.4 SET EX PX NX + verifica el valor aleatorio único y lo vuelve a borrar (se soluciona el problema del borrado accidental, aún existe el problema del bloqueo caducado y el negocio no se ejecuta)

if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
　　}
　　finally {
       //判断是不是当前线程加的锁,是才释放
       if (uni_request_id.equals(jedis.get(key_resource_id))) {
        jedis.del(lockKey); //释放锁
        }
    }
}
复制代码

Aquí, juzgar si el bloqueo agregado y liberado por el hilo actual no es una operación atómica. Si llama a jedis.del () para liberar el bloqueo, es posible que el bloqueo ya no pertenezca al cliente actual y se liberará el bloqueo agregado por otros.

Generalmente use el script lua en su lugar. El script lua es el siguiente:

if redis.call('get',KEYS[1]) == ARGV[1] then 
   return redis.call('del',KEYS[1]) 
else
   return 0
end;
复制代码

3.1.5 El marco de Redisson + el algoritmo Redlock resuelve el problema de la liberación de la cerradura caducada, la ejecución comercial incompleta + el problema independiente

Redisson utiliza una Watch dogsolución para resolver el problema de la caducidad y liberación del bloqueo, y el negocio no se ejecuta. El diagrama esquemático de Redisson es el siguiente:

Los bloqueos distribuidos anteriores todavía tienen problemas independientes:

Si el subproceso uno obtiene el bloqueo en el nodo maestro de Redis, pero la clave bloqueada no se ha sincronizado con el nodo esclavo. Exactamente en este momento, cuando el nodo maestro falla, un nodo esclavo se actualizará a un nodo maestro. El hilo dos puede adquirir el candado de la misma llave, pero el hilo uno ya ha adquirido el candado y se pierde la seguridad del candado.

Para problemas independientes, se puede utilizar el algoritmo Redlock. Los amigos que estén interesados pueden leer mi artículo, ¡ siete soluciones! Discutir la postura de uso correcta del candado distribuido de Redis

3.2 Precauciones para la coherencia de la caché

Si es una solicitud de lectura, primero lea el caché y luego lea la base de datos
Si es una solicitud de escritura, actualice la base de datos primero y luego escriba en la caché
Cada vez que actualiza los datos, debe borrar el caché
La caché generalmente necesita establecer una cierta invalidación de vencimiento
Si los requisitos de coherencia son altos, se puede utilizar biglog + MQ para garantizar.

Los amigos que estén interesados pueden leer mi artículo: En un entorno concurrente, ¿debería operar primero la base de datos o la caché primero?

3.3 Evalúe adecuadamente la capacidad de Redis para evitar la invalidación del tiempo de vencimiento previamente establecido debido a la cobertura de conjuntos frecuentes.

Sabemos que todos los tipos de estructura de datos de Redis pueden establecer el tiempo de vencimiento. Suponga que una cadena tiene un tiempo de vencimiento establecido y, si lo restablece, el tiempo de vencimiento anterior no será válido.

El setKeycódigo fuente de Redis es el siguiente:

void setKey(redisDb *db,robj *key,robj *val) {
    if(lookupKeyWrite(db,key)==NULL) {
       dbAdd(db,key,val);
    }else{
    dbOverwrite(db,key,val);
    }
    incrRefCount(val);
    removeExpire(db,key); //去掉过期时间
    signalModifiedKey(db,key);
}
复制代码

En el desarrollo comercial real, al mismo tiempo, debemos evaluar razonablemente la capacidad de Redis para evitar la cobertura de conjuntos frecuentes, lo que hará que la clave con el tiempo de vencimiento deje de ser válida. El novato Xiaobai es fácil de cometer este error.

3.4 Problema de penetración de caché

Primero veamos un método común de uso de caché: cuando llega una solicitud de lectura, primero verifique el caché, y si el caché tiene un valor, regresará directamente; si el caché falla, verificará la base de datos y luego actualizará el valor de la base de datos a la caché y luego regrese.

Penetración de caché : se refiere a la consulta de ciertos datos inexistentes, porque se pierde el caché, es necesario consultarlo desde la base de datos y los datos no se encuentran, no se escribirán en el caché, lo que provocará que no se datos existentes para ir a la base de datos cada vez que se realiza una consulta, y luego presionar la base de datos.

En términos simples, cuando se accede a una solicitud de lectura, ni el caché ni la base de datos tienen un valor determinado, lo que hará que cada solicitud de consulta de este valor penetre en la base de datos, que es la penetración del caché.

La penetración de la caché generalmente es causada por estas situaciones:

Diseño comercial irrazonable , por ejemplo, la mayoría de los usuarios no tienen guardias, pero todas sus solicitudes se almacenan en caché y puede consultar si un determinado ID de usuario está protegido.
Los errores en el negocio / operaciones / desarrollo , como la caché y los datos de la base de datos, se han eliminado por error .
Los piratas informáticos solicitan ataques ilegales , como los piratas informáticos que fabrican deliberadamente una gran cantidad de solicitudes ilegales para leer datos comerciales inexistentes.

¿Cómo evitar la penetración de caché? Generalmente hay tres métodos.

1. Si es una solicitud ilegal, verificamos los parámetros en la entrada de la API para filtrar los valores ilegales.
1. Si la base de datos de la consulta está vacía, podemos establecer un valor nulo o un valor predeterminado para la caché. Pero si llega una solicitud de escritura, la caché debe actualizarse para garantizar la coherencia de la caché y, al mismo tiempo, establecer un tiempo de caducidad apropiado para la caché al final. (De uso común en los negocios, simple y efectivo)
1. Utilice filtros de floración para determinar rápidamente si existen datos. Es decir, cuando entra una solicitud de consulta, el filtro de floración se usa para determinar si el valor existe y luego la consulta continúa.

Principio del filtro Bloom: Consiste en una matriz de mapa de bits con un valor inicial de 0 y N funciones hash. Uno realiza N algoritmos hash en una clave para obtener N valores, y establece estos N valores en 1 después del hash en la matriz de bits, y luego, al verificar, si estas posiciones específicas son todas 1, luego el filtrado de floración El dispositivo determina que el existe la clave.

3.5 Problema de caché Snow Ben

Caching Xueben: se refiere a la gran cantidad de datos en el caché hasta el tiempo de vencimiento, y la cantidad de datos de consulta es enorme, y todas las solicitudes acceden directamente a la base de datos, lo que genera una presión excesiva en la base de datos o incluso un tiempo de inactividad.

El almacenamiento en caché de Xueben generalmente se debe a que una gran cantidad de datos caducan al mismo tiempo, por lo que se puede solucionar estableciendo el tiempo de caducidad de manera uniforme, es decir, haciendo que el tiempo de caducidad sea relativamente discreto. Si usa un valor fijo mayor + un valor aleatorio menor, 5 horas + 0 a 1800 segundos salsa morada.
Las fallas de Redis y el tiempo de inactividad también pueden hacer que la caché se convierta en nieve. Esto requiere la construcción de un clúster de alta disponibilidad de Redis.

3.6 Problema de ruptura de caché

Desglose de la caché: se refiere a cuándo caduca la tecla de acceso rápido en un momento determinado, y en ese momento llega una gran cantidad de solicitudes simultáneas para esta clave, y una gran cantidad de solicitudes llegan a la base de datos.

El desglose del caché se parece un poco, de hecho, la diferencia entre los dos es que el Xueben de caché significa que la base de datos está bajo demasiada presión o incluso que la máquina está inactiva. El desglose del caché es solo una gran cantidad de solicitudes simultáneas a la base de datos DB nivel. Se puede considerar que el desglose es un subconjunto del caché Xueben. Algunos artículos creen que la diferencia entre los dos es que el desglose es para un caché de teclas de acceso rápido, mientras que Xueben tiene muchas teclas.

Hay dos soluciones:

1. Utilice el esquema de bloqueo de mutex . Cuando el caché falla, en lugar de cargar los datos de la base de datos inmediatamente, primero use algunos comandos de operación atómica con un retorno exitoso, como (Redis setnx) para operar, y luego cargue los datos de la base de datos de la base de datos y configure la caché cuando tenga éxito. De lo contrario, intente recuperar el caché nuevamente.
2. "Nunca caducar" significa que cuando no se establece el tiempo de caducidad, pero los datos activos están a punto de caducar, el subproceso asincrónico se actualiza y establece el tiempo de caducidad.

3.7. Problema de la tecla de acceso rápido de la caché

En Redis, llamamos a las claves con alta frecuencia de acceso como claves de hotspot. Si se envía una solicitud de una tecla de acceso rápido al host del servidor, debido a la gran cantidad de solicitudes, el host puede ser insuficiente en recursos o incluso en tiempo de inactividad, lo que afecta los servicios normales.

¿Y cómo se genera la tecla de acceso rápido? Hay dos razones principales:

Los datos consumidos por los usuarios son mucho más grandes que los datos producidos, como picos, noticias de actualidad y otros escenarios donde se lee más y menos se escribe.

La fragmentación de solicitudes está concentrada, lo que supera el rendimiento de un solo servidor Redi. Por ejemplo, con una clave de nombre fija y un Hash en el mismo servidor, el tráfico instantáneo es extremadamente grande, superando el cuello de botella de la máquina y provocando problemas de teclas de acceso rápido.

Entonces, en el desarrollo diario, ¿cómo identificar la tecla de acceso rápido?

Juzgar cuáles son las teclas de acceso rápido según la experiencia;

Informe de estadísticas del cliente;

Informes de capa de agente de servicio

¿Cómo resolver el problema de la tecla de acceso rápido?

Expansión del clúster de Redis: aumente las copias de fragmentos para equilibrar el tráfico de lectura;

Hash la tecla de acceso rápido, como hacer una copia de seguridad de una clave como key1, key2 ... keyN, N copias de seguridad de los mismos datos, N copias de seguridad distribuidas a diferentes fragmentos y acceso aleatorio a una de las N copias de seguridad durante el acceso. tráfico;

Utilice la caché de segundo nivel, la caché local de JVM, para reducir las solicitudes de lectura de Redis.

4. Operación y mantenimiento de la configuración de Redis

4.1 Utilice conexiones largas en lugar de conexiones cortas y configure correctamente el grupo de conexiones del cliente

Si usa una conexión corta, debe pasar por el protocolo de enlace de tres vías de TCP y cuatro manos agitadas cada vez, lo que aumentará el tiempo. Sin embargo, para una conexión larga, establece una conexión una vez y los comandos redis se pueden usar todo el tiempo. Jiangzi puede reducir el tiempo para establecer una conexión redis.
El grupo de conexiones puede establecer múltiples conexiones en el cliente sin liberarlas.Cuando se necesita una conexión, no es necesario crear una conexión cada vez, lo que ahorra tiempo. Pero debe establecer los parámetros de manera razonable y debe liberar los recursos de conexión a tiempo cuando no opere Redis durante mucho tiempo.

4.2 Utilice únicamente db0

La arquitectura independiente de Redis prohíbe el uso de no db0. Hay dos razones

Para una conexión, Redis ejecuta el comando seleccione 0 y seleccione 1 para cambiar, lo que consumirá nueva energía.
Redis Cluster solo admite db0, si desea migrar, el costo es alto

4.3 Establecer maxmemory + estrategia de eliminación adecuada.

Para evitar que la acumulación de memoria se hinche. Por ejemplo, a veces, el volumen de negocio ha aumentado, la clave redis se usa mucho, la memoria es directamente insuficiente y el hermano de operación y mantenimiento también se olvidó de aumentar la memoria. ¿Redis simplemente cuelga así? Por lo tanto, es necesario seleccionar maxmemory-policy (estrategia de eliminación de memoria máxima) y establecer el tiempo de vencimiento de acuerdo con el negocio real. Hay un total de 8 estrategias de eliminación de memoria:

Volatile-lru: cuando la memoria es insuficiente para acomodar los datos recién escritos, se usa el algoritmo LRU (menos usado recientemente) para eliminar la clave con el tiempo de vencimiento;
allkeys-lru: cuando la memoria es insuficiente para acomodar los datos recién escritos, se utiliza el algoritmo LRU (menos utilizado recientemente) para eliminar todas las claves.
Volatile-lfu: Nuevo en la versión 4.0 Cuando la memoria es insuficiente para acomodar los datos recién escritos, se usa el algoritmo LFU para eliminar la clave de la clave caducada.
allkeys-lfu: Nuevo en la versión 4.0, cuando la memoria no es suficiente para acomodar los datos recién escritos, el algoritmo LFU se usa para eliminar todas las claves;
Volátil-aleatorio: cuando la memoria no es suficiente para contener los datos recién escritos, los datos se eliminan aleatoriamente de la clave con el tiempo de caducidad establecido ;.
allkeys-random: cuando la memoria es insuficiente para acomodar los datos recién escritos, los datos se eliminan aleatoriamente de todas las claves.
Volatile-ttl: Cuando la memoria no es suficiente para acomodar los datos recién escritos, entre las claves con el tiempo de caducidad establecido, la clave se eliminará de acuerdo con el tiempo de caducidad, y la caducada anterior se eliminará primero;
noeviction: la estrategia predeterminada, cuando la memoria no es suficiente para acomodar los datos recién escritos, la nueva operación de escritura informará un error.

4.4 Habilitar mecanismo de perezoso

La versión de Redis4.0 + es compatible con el mecanismo de lazy-free. Si su Redis todavía tiene bigKey, se recomienda habilitar la lazy-free. Cuando está activado, si Redis elimina una clave grande, la operación de liberación de memoria que consume mucho tiempo se ejecutará en el subproceso en segundo plano, reduciendo el impacto de bloqueo en el subproceso principal.

Autor: snail boy picking
link: https: //juejin.cn/post/6942643266613411854
Fuente: Nuggets