Fortalecimiento de Redis (principio de caché, eliminación de caché, penetración de caché, ruptura de caché, avalancha de caché, persistencia de Redis)

Endurecimiento Redis

Principios de uso de caché

¿Cuándo y qué tipo de datos se pueden almacenar en Redis?

1. La cantidad de datos no debe ser demasiado grande

2. Cuanto más se utilice, más rentable es que Redis guarde estos datos

3. Los datos almacenados en Redis generalmente no se modifican con frecuencia en la base de datos.

Política de eliminación de caché

Redis almacena datos en la memoria y la capacidad de la memoria es limitada. Si la memoria del servidor Redis está llena y necesita guardar nuevos datos en Redis ahora, cómo hacerlo es la estrategia de eliminación de caché.

• noeviction: devuelve un error **(predeterminado)**

Si no queremos que se equivoque, podemos configurarlo para que elimine la información que cumpla ciertas condiciones y luego guarde la nueva información.

• allkeys-random: elimina aleatoriamente datos de todos los datos
• volátil-aleatorio: elimine aleatoriamente datos de datos con un tiempo de vencimiento
• volatile-ttl: elimina los datos con el menor tiempo válido restante
• allkeys-lru: elimine los datos con el tiempo de último uso más largo desde el presente entre todos los datos
• volatile-lru: elimine los datos con el tiempo más largo desde el último uso de los datos con un tiempo de caducidad
• allkeys-lfu: elimina los datos usados ​​con menos frecuencia entre todos los datos
• volatile-lfu: elimine los datos utilizados con menos frecuencia con un tiempo de vencimiento

Tiempo para vivir (ttl)

Utilizado menos recientemente (lru)

Usado con menos frecuencia (lfu)

penetración de caché

La llamada penetración de caché significa que una solicitud comercial primero consulta redis, y redis no tiene estos datos, luego va a consultar la base de datos, pero la base de datos tampoco los tiene.

En condiciones comerciales normales, después de que una solicitud consulta datos, podemos guardar los datos en Redis, y las solicitudes posteriores se pueden consultar directamente desde Redis sin conectarse a la base de datos. Sin embargo, una vez que ocurre el fenómeno de penetración anterior, aún es necesario conectarse a la base de datos. Una vez conectado a la base de datos, la eficiencia general del proyecto se verá afectada. Si hay solicitudes maliciosas y acceso de alta concurrencia a datos que no existen en la base de datos, en casos graves, el servidor actual puede estar caído.

La solución principal en la industria: filtro Bloom.

Cómo usar el filtro Bloom

1. Genere un filtro Bloom para todos los datos existentes y guárdelo en Redis;

2. En la capa de lógica de negocios, verifique si la identificación está en el filtro Bloom antes de juzgar a Redis;

3. Si el filtro Bloom juzga que el id no existe, devuélvelo directamente;

4. Si el filtro Bloom considera que existe la identificación, realice la ejecución comercial posterior.

desglose de caché

Un plan para guardar datos en Redis, consulta comercial, los datos consultados no existen en Redis, pero existen en la base de datos. En este caso, deben consultarse desde la base de datos y luego guardarse en Redis.

El traspaso de caché en sí mismo no es un problema catastrófico, ni es un fenómeno inaceptable.

avalancha de caché

Como se mencionó anteriormente, es normal que ocurra una pequeña cantidad de fallas al mismo tiempo, pero si ocurre una gran cantidad de fallas al mismo tiempo, será de la siguiente manera:

La llamada avalancha de caché se refiere a los datos almacenados en Redis. Una gran cantidad de datos caducan al mismo tiempo en un corto período de tiempo. Como se muestra en la figura anterior, la información que debería haber sido retroalimentada por Redis, porque Avalanche ha visitado Mysql, Mysql no puede soportarlo, lo que puede causar una excepción. Para evitar esto, debe evitar una gran cantidad de invalidaciones de caché al mismo tiempo.

La razón por la que una gran cantidad de cachés se invalidan al mismo tiempo: generalmente se debe a que se establece el mismo período de validez para los datos cargados al mismo tiempo.

Podemos evitar que una gran cantidad de datos se invaliden al mismo tiempo agregando un número aleatorio al configurar el período de validez.

Redis persistencia

Redis guarda información en la memoria. La característica de la memoria es que una vez que se apaga la alimentación, toda la información se pierde. Para Redis, después de que se pierden todos los datos y luego se vuelven a cargar, todos los datos deben volver a consultarse desde la base de datos. Esta operación no solo requiere mucho tiempo, sino que también ejerce mucha presión sobre la base de datos.

Además, para algunas empresas, los datos primero se guardan en Redis y luego se sincronizan con la base de datos a intervalos. Si se apaga Redis, los datos durante este período se perderán por completo. Para evitar que el reinicio de Redis cause una presión adicional en la base de datos y la pérdida de datos, Redis admite la función de persistencia.

La llamada persistencia consiste en guardar los datos guardados en Redis en el disco duro del servidor Redis actual de una manera específica. Si existe en el disco duro, los datos no se perderán cuando se apague. Cuando Redis se inicie de nuevo, la información en el disco duro se usará para restaurar los datos.

Hay dos estrategias para que Redis logre la persistencia:

RDB:(Copia de seguridad de la base de datos de Redis)

RDB es esencialmente una instantánea de la base de datos (es decir, todos los datos en Redis se convierten actualmente en objetos binarios y se almacenan en el disco duro). De forma predeterminada, cada copia de seguridad generará un archivo dump.rdb. Cuando Redis está apagado o apagado, cuando se reinicia, restaurará los datos de este archivo y obtendrá todo el contenido de dump.rdb. Para lograr este efecto, podemos agregar la siguiente información al archivo de configuración de Redis:

save 60 5

En la configuración anterior, 60 significa segundos y 5 significa la cantidad de veces que se ha modificado la clave Redis.

Efecto de la configuración: si se modifican más de 5 claves en 1 minuto, se iniciará el programa de instantáneas de la base de datos rdb.

ventaja:

• Debido a que es el formato binario de los datos generales de Redis, la recuperación de datos se realiza como un todo.

defecto:

• El archivo rdb generado es un archivo en el disco duro y la eficiencia de lectura y escritura es baja;
• Si hay una falla de energía repentina, solo se pueden restaurar los datos en el último rdb generado.

AOF (Agregar solo archivo):

La estrategia de AOF es hacer una copia de seguridad de todos los comandos (registros) que ha ejecutado Redis y guardarlos en el disco duro, de modo que incluso si Redis está apagado, podemos restaurarlo al estado anterior a la falla de energía en función de los registros que se han ejecutado Podemos agregar la siguiente información de configuración al archivo de configuración de Redis:

appendonly yes

Después de esta configuración, se puede guardar el registro del comando que se ha ejecutado. En teoría, cualquier comando que se haya ejecutado se puede restaurar, pero en realidad, cuando Redis está muy ocupado, almacenaremos en caché el comando de registro y lo enviaremos a la copia de seguridad como un todo, reduciendo la cantidad de io para mejorar el rendimiento de la copia de seguridad y el impacto en el rendimiento de Redis. En el desarrollo real, la configuración generalmente adopta la estrategia de enviar archivos de registro una vez por segundo, y los datos se perderán durante 1 segundo como máximo cuando se apague.

ventaja:

En comparación con RDB, se pierde menos información.

defecto:

Debido a que el registro en ejecución se guarda, ocupa mucho espacio.

En el desarrollo real, RDB y AOF se pueden habilitar al mismo tiempo o de forma selectiva.

AOF de Redis admite la reescritura de AOF para reducir el tamaño de los archivos de registro

En pocas palabras, es eliminar declaraciones no válidas en el registro, lo que puede reducir el espacio ocupado

Principio de almacenamiento Redis

Cuando escribimos negocios de código Java, si necesitamos encontrar un elemento de una colección de múltiples elementos, o verificar la ausencia de una clave, se recomienda que usemos HashMap o HashSet, porque esta estructura de datos tiene la mayor eficiencia de consulta, porque se usa internamente.

"tabla de picadillo"

La siguiente figura es el principio de almacenamiento de la tabla hash

Cuantas más ranuras, mayor es el rendimiento de la consulta cuando hay más elementos. HashMap tiene 16 ranuras por defecto.

La capa inferior de Redis también utiliza una estructura de tabla hash para almacenar datos. Redis divide la memoria en 16384 áreas (similares a las ranuras hash), calcula un valor para la clave de los datos utilizando el algoritmo CRC16 y toma el resto 16384. El resultado es 0~16383, por lo que Redis puede buscar elementos de manera muy eficiente.

clúster de Redis

El estado mínimo de Redis es un servidor. El estado de ejecución de este servidor determina directamente si Redis está disponible. Si está fuera de línea, Redis no estará disponible para todo el proyecto y el sistema se bloqueará. Para evitar que esto suceda, podemos preparar una máquina de respaldo.

replicación maestro-esclavo

Es decir, cuando el maestro (master) está funcionando, organice una máquina de respaldo (esclavo) para sincronizar datos en tiempo real. En caso de que el maestro se caiga, podemos cambiar a la máquina de respaldo para ejecutar.

Desventajas: en tal esquema, el nodo esclavo no tiene un efecto real. Mientras el maestro no se caiga, es lo mismo que nada y no refleja el valor.

separación de lectura y escritura

De esta manera, el esclavo también puede compartir el trabajo del maestro cuando el maestro funciona normalmente, pero si el maestro está caído, el cambio entre el maestro y las máquinas de reserva aún requiere intervención manual, lo que aún lleva tiempo. Entonces, si desea lograr un cambio automático cuando ocurre una falla, debe tener una estrategia fija configurada.

Modo centinela : conmutación automática de conmutación por error

El nodo centinela envía solicitudes a todos los nodos a intervalos regulares. Si la respuesta es normal, se considera que el nodo es normal. Si no hay respuesta, se considera que el nodo tiene un problema. El centinela puede cambiar automáticamente entre las máquinas principal y de reserva. Si el maestro del host se desconecta, cambiará automáticamente a la máquina de reserva para operar.

Sin embargo, si el centinela comete un error al juzgar el estado del nodo, desconectará al maestro por error y reducirá el rendimiento operativo general, por lo que se debe reducir la posibilidad de un error de juicio del centinela.

Cúmulo centinela

Podemos convertir los nodos centinela en un clúster y varios centinelas votan para decidir si desconectarse de un nodo determinado. En el clúster centinela, cada nodo enviará solicitudes de ping al maestro y al esclavo con regularidad. Si más de dos nodos centinela (la mitad de los nodos en el clúster) no reciben una respuesta normal a la solicitud de ping, el nodo se considerará desconectado. Cuando el negocio continúa expandiéndose y la concurrencia continúa aumentando.

Clúster fragmentado

Cuando solo un nodo admite operaciones de escritura y no puede cumplir con los requisitos generales de rendimiento, el rendimiento del sistema llegará al cuello de botella. En este momento, necesitamos implementar varios nodos que admitan operaciones de escritura para fragmentación para mejorar el rendimiento general del programa.

La fragmentación significa que cada nodo es responsable de un área diferente.

Por ejemplo, la ranura Redis 0~16383:

MasterA es responsable de 0~5000

MasterB es responsable de 5001~10000

MasterC es responsable de 10001~16383

Una clave solo puede obtener resultados fijos de acuerdo con el algoritmo CRC16, y los datos deben encontrarse en el servidor especificado.

Con esta estructura de clúster, podemos procesar las solicitudes comerciales de manera más estable y eficiente.

Para ahorrar el costo del servidor centinela, algunas empresas agregan directamente la función centinela en el clúster de Redis, de modo que los nodos maestro/esclavo puedan verificar el estado de salud de los demás mientras completan las tareas de lectura y escritura de datos.