aprendizaje de puntos de conocimiento redis

estructura básica de datos

Cadena : el escenario de uso del tipo Cadena: ¡el valor puede ser un número además de una cadena!
Contadores, contando el número de unidades múltiples, el número de ventiladores, almacenamiento de caché de objetos.
Lista : la lista de listas es una lista simple de cadenas, ordenadas según el orden de inserción. Puede agregar un elemento al principio (izquierda) o al final (derecha) de la lista
Conjunto : tipo de conjunto, deduplicación desordenada, escenario de aplicación: los amigos se prestan atención entre sí
Hash : tipo de hash, clave-[campo: valor], aplicación escenario: más Adecuado para almacenar información de objetos (cambiar información), como hmset usuario: 1 nombre "zhmsky" edad 23
Zet : tipo Zset, colección ordenada, salario zadd 21000 zhmsky, escenarios de aplicación: clasificación básica, clasificación ponderada, tabla de clasificación

asuntos

La transacción redis es una operación de aislamiento independiente: todos los comandos de la transacción se serializarán y ejecutarán en orden, y la transacción no se verá interrumpida por los comandos enviados por otros clientes durante la ejecución. La función principal de la transacción redis es concatenar varios comandos para evitar que otros salten la cola.

Iniciar transacción : comando múltiple (todos los comandos subsiguientes entrarán en la cola de espera)
Ejecutar transacción : comando exec (ejecutar todos los comandos en la cola de espera en orden al mismo tiempo)
Abandonar transacción : descartar comando

Las transacciones de Redis no son compatibles con las características ACID Tres características de las transacciones de Redis:
1. Operación de aislamiento separada: todos los comandos en una transacción se serializarán y ejecutarán en orden. La transacción no será interrumpida por solicitudes enviadas por otros clientes durante la ejecución.
2. No existe el concepto de nivel de aislamiento: los comandos en la cola no se ejecutarán realmente hasta que se envíen
3. La atomicidad no está garantizada: si un comando no se ejecuta en la transacción, los comandos subsiguientes aún se ejecutarán sin retroceder

manejo de errores de transacción

1. Se produjo un error de informe en un determinado comando en el equipo, y todos los comandos en toda la cola de espera se cancelaron durante la ejecución (error de sintaxis de comando);
2. Si se produce un error en un determinado comando durante la ejecución, solo no se ejecutará el comando que informa el error, y se ejecutarán otros comandos normales (el tipo no coincide)

Bloqueo pesimista : Es decir, es muy pesimista. Cada vez que obtienes el dato, piensas que otros lo modificarán, por lo que cada vez que obtienes el dato, lo bloquearás. Solo cuando obtienes el bloqueo, puedes tener la operación
. autoridad. (bloqueos de fila, bloqueos de tabla, bloqueos de lectura/escritura), baja eficiencia

Bloqueo optimista : Es muy optimista, cada vez que vas a buscar los datos, piensas que otros no lo modificarán, por lo que no se bloqueará, pero al actualizar, juzgará si alguien ha actualizado los datos durante este período ( al introducir el campo de versión del número de versión), el bloqueo optimista es adecuado para escenarios de aplicaciones de lectura múltiple. Redis también utiliza este mecanismo para implementar transacciones.
El monitor de vigilancia se puede usar como un bloqueo optimista: antes de ejecutar multi, primero ejecute la tecla de vigilancia 1 (clave 2), y una (o más) teclas pueden ser monitoreadas. Si esta (o estas) claves se modifican con otros comandos antes de que se ejecutado, entonces la transacción será interrumpida

redis persistencia

RDB (Redis DataBase) : escriba la instantánea del conjunto de datos en la memoria (instantánea instantánea) en el disco dentro de un intervalo de tiempo específico y lea el archivo de la instantánea directamente en la memoria al restaurar; redis creará un proceso secundario separado para la persistencia, primero
escriba los datos en un archivo temporal, después de que termine el proceso de persistencia, luego use este archivo temporal para reemplazar el último archivo persistente y convertirse en el archivo RDB oficial; la desventaja de RDB es que los últimos datos persistentes pueden perderse.
Mecanismo de activación:
1. Cuando se cumplan las reglas de sava, los archivos RDB se generarán automáticamente
2. Ejecute el comando flushall y también se generarán los archivos RDB
3. Salga de redis y los archivos RDB se generarán automáticamente

AOF (agregar solo archivo) : registre cada operación de escritura en forma de registro, registre todas las instrucciones ejecutadas por Redis (las operaciones de lectura no se registran), solo agregue pero no reescriba archivos, Redis leerá al comienzo del inicio Tome el archivo para reconstruir los datos, es decir, ejecute el comando de escritura de adelante hacia atrás según el contenido del archivo de registro para completar la recuperación de datos.

replicación redis maestro-esclavo

Se refiere a copiar los datos de un servidor redis a otros servidores redis. El primero es el nodo maestro (maestro) y el segundo es el nodo esclavo (esclavo); la replicación de datos es unidireccional, solo desde el nodo maestro al nodo esclavo, el maestro es principalmente para escribir y el esclavo es principalmente para leer.

Solo hay un host por defecto, comando SlaveOf 127.0.0.1 6379: subordinado al puerto 6379 del host 127.0.0.1; ¡el host puede escribir, el esclavo no puede escribir pero solo puede leer! ¡Toda la información y los datos en el maestro serán guardados automáticamente por el esclavo! Sin embargo, es mejor usar el archivo de configuración (permanente) para configurar la máquina esclava. Si usa la línea de comando para configurar la máquina esclava, cuando la máquina esclava se apaga y luego restablece la conexión, la máquina esclava se configurará automáticamente como máquina maestra.

principio de replicación

Después de que la máquina esclava se conecte con éxito al host, enviará un comando de sincronización;
el host recibe el comando, inicia el proceso de guardado en segundo plano y recopila todos los comandos recibidos para modificar el conjunto de datos. Después de ejecutar el proceso en segundo plano, el host transmitirá todo el archivo de datos al esclavo, completará una sincronización completa.

Copia completa: después de recibir todo el archivo de la base de datos, el esclavo lo guarda y lo carga en la memoria;
Copia incremental: el host continúa transmitiendo todos los nuevos comandos de modificación recopilados al esclavo para completar la sincronización;

Seleccione manualmente el modo jefe (anfitrión): el comando SlaveOf no one puede establecer el nodo actual como el nodo maestro (anfitrión)

Modo centinela (seleccionar host automáticamente)

Redis proporciona un mecanismo de centinela. El centinela se ejecuta de forma independiente como un proceso independiente. El principio es que el centinela supervisa varias instancias de redis en ejecución mediante el envío de comandos y esperando que el servidor de redis responda. Cuando el centinela detecta que el host está inactivo, cambiará automáticamente el esclavo al maestro y luego notificará a otros esclavos que modifiquen el archivo de configuración a través del modo de publicación y suscripción para cambiar al maestro (se pueden configurar múltiples centinelas y grupos de centinelas );

Si el host falla, Sentinel votará automáticamente por un nuevo host y, cuando el host original vuelva a estar en línea, se restablecerá automáticamente como esclavo.

clúster redis

La capacidad del servidor redis no es suficiente, ¿cómo expandir la capacidad de redis? Frente a una gran cantidad de operaciones de escritura simultáneas, ¿cómo se asigna Redis?
-----Crear un clúster

Método de establecimiento del clúster: se recomienda adoptar una configuración de clúster no centralizada. Por ejemplo, hay 3 servidores redis, cada uno de los cuales almacena información de usuario, producto y pedido, y los 3 servidores son seriales (es decir, cada uno de los servidores se puede usar como una entrada, para lograr una función similar a reenvío)

Penetración de caché (no se puede encontrar)

Cuando el usuario consulta los datos, primero va a la memoria caché redis y descubre que no hay memoria caché, es decir, la memoria caché no se ve afectada, por lo que consulta la base de datos de la capa de persistencia y descubre que no la hay. Cuando una gran cantidad de usuarios van a consultar, el caché no golpea (segundo asesinato), por lo que todos solicitan la base de datos de la capa de persistencia, lo que ejercerá presión sobre la base de datos de la capa de persistencia, que es equivalente a la penetración del caché.

Fenómeno principal :

1. Redis no puede consultar datos (la tasa de aciertos cae rápidamente)
2. Hay muchos accesos a URL anormales (la penetración de la memoria caché es equivalente a que la memoria caché redis no funcione)

Solución :

1. filtro de floración
2. Coloque un objeto vacío (es decir, cuando los datos no se puedan consultar en el caché de redis, coloque un valor vacío para que actúe como caché y establezca el tiempo de vencimiento del valor vacío para que sea muy corto, no más de 5 minutos)
3. Configurar una lista accesible (lista blanca)

Desglose del caché (la cantidad es demasiado grande, caduca cierto caché de clave)

Significa que una determinada clave es muy activa y constantemente lleva una alta concurrencia y accede a un punto de manera centralizada. Cuando la clave deja de ser válida, la gran concurrencia continua romperá el caché y solicitará directamente la base de datos de la capa de persistencia. La presión sobre la base de datos es instantáneamente excesiva.

Solución :

1. Datos de puntos de acceso preestablecidos para aumentar el tiempo efectivo de la clave de datos de puntos de acceso
2. Bloqueos distribuidos (como setnx)

Avalancha de caché (vencimiento centralizado de una gran cantidad de claves de caché)

En un cierto período de tiempo, una gran cantidad de claves de caché caducan y se vuelven inválidas (provocando así un rápido aumento en la presión de acceso a la base de datos de la capa de persistencia, ralentizando la respuesta de la base de datos, ralentizando la respuesta de la solicitud, causando una gran cantidad de solicitudes para esperar en redis, lo que hace que el servidor redis se bloquee) o el tiempo de inactividad de redis

Solución :

1. Cree una arquitectura de caché de varios niveles: caché nginx + caché redis + otros cachés
2. Usar bloqueos o colas
3. Configure el indicador de caducidad para actualizar el caché (cuando la clave de caché esté a punto de caducar, active otro hilo por adelantado para actualizar el caché de la clave real en segundo plano)
4. Distribuya el tiempo de caducidad de la caché (minimice el tiempo de caducidad de la clave de caché en el mismo período de tiempo tanto como sea posible)

Bloqueo distribuido (el núcleo es setnx)

¿Por qué necesita bloqueos distribuidos?
----Con el desarrollo del negocio, después de que el sistema independiente original evolucionara gradualmente hacia un sistema de clúster distribuido, debido a los subprocesos múltiples, procesos múltiples y distribución del sistema distribuido en diferentes máquinas, el sistema independiente original el bloqueo de control de concurrencia falla, para resolver este problema se requiere un mecanismo de exclusión mutua entre JVM para controlar el acceso a los recursos compartidos.

Use redis para implementar bloqueos distribuidos

1. configure key 10 nx ex 10 lock y configure el tiempo de vencimiento al mismo tiempo, para resolver el problema de que el bloqueo no se ha liberado
2. expire(tiempo de "bloqueo") del("bloqueo") libera el bloqueo

Problemas que pueden surgir :
1. Eliminación por error

1. Supongamos que hay tres servidores (a, b, c) para operar ciertos datos, ahora agarra el candado primero para operar;
2. a Tome el bloqueo y bloquéelo para realizar operaciones comerciales, pero de repente el servidor se congela (la función comercial no se completa en este momento), pero el bloqueo se libera automáticamente debido al tiempo de espera;
3. b agarra el bloqueo en este momento y ejecuta la operación comercial, pero después de un tiempo, a reacciona y continúa ejecutando la operación comercial. Cuando se completa el negocio, el bloqueo se libera manualmente. En este momento, b no ha terminado de ejecutar, pero el bloqueo es liberado por un

Resuelva el problema de eliminación por error anterior (use uuid para resolver la eliminación por error):

1. establecer bloqueo uuid nx ex 10 Establecer uuid para representar diferentes operaciones
2. if(uuid.equals(redisUtils.get(“lock”))){redisUtils.delete(“lock”)} Al liberar el bloqueo, juzgue si el uuid de la operación actual es igual al uuid del bloqueo, de modo que el bloqueo se puede liberar manualmente

2. Falta de atomicidad

1. Suponiendo que hay dos servidores (a, b) para operar ciertos datos, ahora agarra el candado primero para realizar operaciones comerciales;
2. Al liberar el bloqueo, primero compare el uuid y descubra que es el mismo. Cuando el bloqueo está a punto de liberarse manualmente pero aún no se ha liberado, el bloqueo se libera automáticamente después del tiempo de espera;
3. Luego, b toma el candado para realizar operaciones comerciales y a lo libera manualmente, lo que provoca una eliminación errónea.
   Solución : use el script lua para garantizar la atomicidad.