Problemas relacionados con el clúster de Redis

Hablar sobre la función de replicación de redis.

En Redis, los usuarios pueden ejecutar el comando SLAVEOF o configurar la opción slaveof para permitir que un servidor replique (replique) otro servidor. Al servidor replicado lo llamamos maestro, y al servidor replicado se le llama esclavo, como se muestra en la figura.

Función de replicación de redis de la versión anterior (antes de 2.8)

La función de replicación de Redis se divide en dos operaciones: sincronización y propagación de comandos:

• La operación de sincronización se utiliza para actualizar el estado de la base de datos del servidor esclavo al estado actual de la base de datos del servidor principal.
• La operación de propagación de comandos se utiliza para cambiar el estado de la base de datos del servidor maestro y hacer que el estado de la base de datos de los servidores maestro y esclavo sea inconsistente, de modo que las bases de datos de los servidores maestro y esclavo vuelvan a un estado consistente.

A continuación, se introducirán en detalle las dos operaciones de sincronización y propagación de comandos.

Sincronizar

Cuando el cliente envía el comando SLAVEOF al servidor esclavo para solicitar al servidor esclavo que replique el servidor maestro, el servidor esclavo primero necesita realizar una operación de sincronización, es decir, actualizar el estado de la base de datos del servidor esclavo al estado actual de la base de datos de el servidor maestro. La operación de sincronización del servidor esclavo con el servidor maestro debe completarse enviando un comando SYNC al servidor maestro. Los siguientes son los pasos de ejecución del comando SYNC:

1. El servidor esclavo envía el comando SYNC al servidor maestro.
2. El servidor principal que recibe el comando SYNC ejecuta el comando BGSAVE, genera un archivo RDB en segundo plano y usa un búfer para registrar todos los comandos de escritura ejecutados a partir de ahora.
3. Cuando se ejecuta el comando BGSAVE del servidor maestro, el servidor maestro enviará el archivo RDB generado por el comando BGSAVE al servidor esclavo, recibirá y cargará el archivo RDB desde el servidor y actualizará el estado de la base de datos al estado de la base de datos cuando el El servidor maestro ejecuta el comando BGSAVE.
4. El servidor maestro envía todos los comandos de escritura registrados en el búfer al servidor esclavo, y el servidor esclavo ejecuta estos comandos de escritura para actualizar el estado de su base de datos al estado actual de la base de datos del servidor maestro.

Propagación de comandos

Una vez finalizada la operación de sincronización, las bases de datos de los servidores maestro y esclavo alcanzarán un estado coherente, pero esta coherencia no es estática. Siempre que el servidor maestro ejecute un comando de escritura enviado por el cliente, la base de datos del servidor maestro puede ser modificada Y porque el estado del servidor maestro y esclavo ya no es consistente.

Por ejemplo, suponga que un servidor maestro y un servidor esclavo acaban de completar la operación de sincronización y sus bases de datos almacenan las mismas cinco claves k1 a k5. Si en este momento, el cliente envía un comando DEL k3 al servidor maestro, luego de que el servidor maestro ejecuta el comando DEL, la base de datos de los servidores maestro y esclavo será inconsistente: la base de datos del servidor maestro ya no contiene la clave k3, pero la clave aún está contenida en la base de datos del servidor esclavo. Para que los servidores maestro y esclavo vuelvan a un estado consistente nuevamente, el servidor maestro necesita realizar operaciones de propagación de comandos en los servidores esclavos: el servidor maestro enviará el comando de escritura que ejecuta, es decir, el comando de escritura que causó los servidores maestro y esclavo sean inconsistentes, al servidor esclavo Ejecutar, cuando el servidor esclavo ejecute el mismo comando de escritura, el servidor maestro y esclavo volverán al estado consistente nuevamente. Esta es la propagación de comandos

En pocas palabras, los comandos de modificación hechos por el servidor maestro al servidor deben ser ejecutados una vez por el servidor esclavo.

Defectos de la versión anterior de la función de replicación.
Para la replicación inicial, la versión anterior de la función de replicación puede completar la tarea muy bien, pero para la repetición después de una desconexión, la versión anterior de la función de replicación también puede hacer que el los servidores maestro y esclavo vuelven a un estado consistente, pero la eficiencia no es muy baja. La razón es que si se quiere mantener la consistencia maestro-esclavo luego de la desconexión, se debe volver a conectar el servidor esclavo para seguir los pasos de la replicación inicial nuevamente. Esto hará que los datos que ya existían en el servidor esclavo sean operaciones repetidas, lo cual es un desperdicio El tiempo consume recursos de la CPU.

Por ejemplo, los
servidores maestro y esclavo ahora son consistentes y almacenan 1000 pares clave-valor. En este momento, el maestro y el esclavo se desconectan y el servidor esclavo intenta volver a conectarse. Durante el proceso de reconexión, el servidor maestro almacena <clave1, value1>, <key2, value2> Dos nuevos pares clave-valor. Después de que el servidor esclavo se vuelve a conectar, se encuentra que el maestro y el esclavo son inconsistentes. Si desea mantener el mismo, el servidor esclavo debe pasar por el primero copie los pasos nuevamente y ejecute el archivo rdb pasado por el servidor maestro, y el servidor esclavo solo quiere agregar dos nuevos pares clave-valor para mantener el maestro-esclavo consistente, pero el archivo rdb contiene 1002 operaciones de pares clave-valor.

La nueva versión de la función de replicación de redis (después de 2.8)

Para resolver la ineficiencia de la versión anterior de la función de replicación para lidiar con la desconexión y la re-replicación, Redis ha utilizado el comando PSYNC en lugar del comando SYNC para realizar la operación de sincronización durante la replicación a partir de la versión 2.8. El comando PSYNC tiene dos modos: resincronización completa y resincronización parcial:

• La resincronización completa se utiliza para manejar la situación de replicación inicial: los pasos de ejecución de la resincronización completa son básicamente los mismos que los pasos de ejecución del comando SYNC. Todos se realizan dejando que el servidor maestro cree y envíe el archivo RDB, y envíe los datos almacenados en el búfer al servidor esclavo Escribir comandos para sincronizar.
• La resincronización parcial se utiliza para manejar la repetición después de la desconexión: cuando el servidor esclavo se vuelve a conectar al servidor maestro después de la desconexión, si las condiciones lo permiten, el servidor maestro puede enviar el comando de escritura ejecutado durante la desconexión del servidor maestro-esclavo al esclavo Siempre que el servidor y el servidor esclavo reciban y ejecuten estos comandos de escritura, pueden actualizar la base de datos al estado actual del servidor maestro.

El modo de resincronización parcial del comando PSYNC resuelve la ineficiencia de la versión anterior de la función de copia al volver a copiar después de una desconexión. La siguiente tabla muestra cómo usar el comando PSYNC para manejar eficientemente la replicación después de la desconexión mostrada en la sección anterior. .
La realización de
la resincronización parcial La función de resincronización parcial consta de las siguientes tres partes:

• El desplazamiento de replicación del servidor maestro y el desplazamiento de replicación del servidor esclavo.
  Analice si la compensación de replicación del servidor maestro es consistente con la compensación de replicación del arma esclava para determinar si los servidores maestro y esclavo están en un estado consistente.
• El retraso en la replicación del servidor primario (registro en la replicación).
  El búfer del registro de copias es una cola de tamaño fijo primero en entrar, primero en salir (FIFO) que mantiene el servidor maestro. El tamaño predeterminado es 1 MB. Se utiliza para almacenar los comandos propagados por el servidor maestro. Al realizar una resincronización parcial, primero determine si los datos después de la compensación de copia existen en el búfer del registro de copias, si es así, realice una resincronización parcial; de lo contrario, realice una sincronización completa
• El ID de ejecución del servidor (ID de ejecución).
  Cuando el servidor esclavo replica el servidor maestro por primera vez, el servidor maestro transmitirá su ID de ejecución al servidor esclavo, y el servidor esclavo guardará la ID de ejecución. Cuando el servidor esclavo se desconecta y se vuelve a conectar a un servidor maestro, el servidor esclavo enviará la ID de ejecución guardada previamente al servidor maestro actualmente conectado: para determinar si este servidor es el servidor maestro previamente conectado o no

Habla sobre el modo Sentinel de redis.

Sentinel (sentinel, sentinel) es una solución de alta disponibilidad para Redis: un sistema Sentinel que consta de una o más instancias de Sentinel (instancias) puede monitorear cualquier número de servidores primarios y los atributos de estos servidores primarios. Cuando el servidor maestro monitoreado se desconecta, uno de los servidores esclavos bajo el servidor maestro fuera de línea se actualizará automáticamente a un nuevo servidor maestro, y luego el nuevo servidor maestro reemplazará al servidor fuera de línea. El servidor principal continúa procesando la solicitud de comando.

La siguiente figura muestra un ejemplo de un servidor de monitoreo del sistema Sentinel que se muestra en la Figura 16-1:

Entre ellos:

• El patrón de anillo doble representa el servidor principal actual server1.
• El patrón de anillo único representa los tres servidores esclavos server2, server3 y server4 del servidor maestro.
• Los tres servidores esclavos server2, server3 y server4 están replicando el servidor maestro serverl, y el sistema centinela está monitoreando los cuatro servidores.

Suponiendo que en este momento, el servidor maestro server1 entra en el estado fuera de línea, entonces se suspenderá la operación de replicación de los servidores esclavos server2, server3, server4 al servidor maestro, y el sistema Sentinel detectará que server1 está fuera de línea, como se muestra en la siguiente figura (servidor fuera de línea indicado por líneas discontinuas).

Cuando la duración fuera de línea del servidor1 excede el límite superior de la duración fuera de línea establecida por el usuario, el sistema Sentinel realizará una operación de conmutación por error en el servidor1:

• Primero, el sistema Sentinel seleccionará uno de los servidores esclavos en el servidor1 y actualizará el servidor esclavo seleccionado al nuevo servidor maestro.
• Después de eso, el sistema Sentinel enviará nuevas instrucciones de replicación a todos los servidores esclavos en el servidor1, convirtiéndolos en servidores esclavos del nuevo servidor maestro.Cuando todos los servidores esclavos comiencen a replicar el nuevo servidor maestro, se completará la operación de conmutación por error.
• Además, Sentinel seguirá supervisando el servidor fuera de línea1 y, cuando vuelva a estar en línea, se establecerá como servidor esclavo del nuevo servidor maestro.

Por ejemplo:
Por ejemplo, la siguiente figura muestra el proceso de actualización del sistema Sentinel server2 a un nuevo servidor maestro y haciendo que los servidores server3 y server4 sean los servidores esclavos de server2.

Después de eso, si el servidor1 vuelve a estar en línea, el sistema Sentinel lo degradará al servidor esclavo del servidor2, como se muestra en la figura siguiente.

¿Cómo detecta el modo centinela de redis si el servidor está fuera de línea?

Detectando el estado fuera de línea de la puerta de enlace maestra.
De forma predeterminada, Sentinel enviará un comando PING a todas las instancias (incluido el servidor maestro, el servidor esclavo y otros Sentinel) que hayan creado una conexión de comando con ella a una frecuencia de una vez por segundo, y devolverlo a través de la instancia Responder al comando PING para determinar si la instancia está en línea.

En el ejemplo que se muestra en la figura siguiente, la línea con flechas muestra cómo Sentinel1 y Sentinel2 envían comandos PING a la instancia:
-Sentinel1 enviará comandos PING a Sentinel2, el servidor maestro y los servidores esclavo esclavo1 y esclavo2.

• Sentinel2 enviará comandos PING a Sentinel1, servidor maestro, esclavo1 y esclavo2. La respuesta de la instancia al comando PING se puede dividir en las siguientes dos situaciones: Respuesta efectiva: La instancia devuelve una de tres respuestas: + PONG, -LOADING y MASTERDOWN.
• Sentinel1 enviará comandos PING a Sentinel2, servidor maestro, esclavo1 y esclavo2. Sentinel2 enviará comandos PING a Sentinel1, servidor maestro, esclavo1 y esclavo2.

La respuesta de la instancia al comando PING se puede dividir en las dos situaciones siguientes:

• Respuesta válida: la instancia devuelve una de tres respuestas: + PONG, -LOADING y MASTERDOWN.
• Respuesta no válida: la instancia devuelve una respuesta distinta de + PONG, -LOADING y MASTERDOWN, o no se devuelve ninguna respuesta dentro del límite de tiempo especificado. "

La opción down-after-milliseconds en el archivo de configuración de Sentinel especifica el tiempo que tarda Sentinel en determinar que la instancia entra en el estado de conexión subjetivo: si una instancia devuelve continuamente respuestas no válidas a Sentinel dentro de los milisegundos de down-after-milisegundos, Sentinel modificará esto. Para la estructura de la instancia correspondiente a la instancia, active el logotipo SRI_s_DOwN en el atributo flags de la estructura para indicar que la instancia ha entrado en el estado subjetivo fuera de línea.

Detectar el estado objetivo fuera de línea

Cuando Sentinel juzga que un servidor principal está fuera de línea, para confirmar si el servidor principal está realmente fuera de línea, pedirá a otros Sentinel que también monitorean este servidor principal para ver si también piensan que el servidor principal ha entrado en estado Fuera de línea (puede ser subjetivo fuera de línea u objetivo fuera de línea). Cuando Sentinel recibe una cantidad suficiente de juicios fuera de línea de otros Sentinel, Sentinel juzgará que el servidor esclavo está objetivamente fuera de línea y realizará una operación de conmutación por error en el servidor principal.

Hable sobre la conmutación por error del modo centinela.
Antes de la conmutación por error, primero debe elegir al líder Sentinel. Debido a que el proceso es más complicado, consulte la sección 16.8 de "Diseño e implementación de Redis".

Una vez elegido el líder Sentinel, el líder Sentinel realizará una operación de conmutación por error en el servidor principal que se ha desconectado. Esta operación incluye los siguientes tres pasos:

• Entre todos los servidores esclavos del servidor maestro fuera de línea, seleccione un servidor esclavo y conviértalo en servidor maestro.
• Cambie todos los servidores esclavos del servidor maestro fuera de línea para replicar el nuevo servidor maestro.
• Configure el servidor maestro fuera de línea como servidor esclavo del nuevo servidor maestro. Cuando el antiguo servidor maestro vuelva a estar en línea, se convertirá en el servidor esclavo del nuevo servidor maestro.

Otros problemas con la solución de clúster de redis

¿Puedes hablar sobre el principio de funcionamiento del modo de clúster de redis?

Redis Cluster es una tecnología de fragmentación del lado del servidor y la versión 3.0 está disponible oficialmente. Redis Cluster no usa un hash consistente, pero usa el concepto de ranura (ranura), que se divide en 16,384 ranuras en total. Envíe la solicitud a cualquier nodo, y el nodo que recibe la solicitud enviará la solicitud de consulta al nodo correcto para su ejecución.

• Al aplicar hash, los datos se fragmentan y cada nodo almacena los datos en un determinado intervalo de ranura hash (valor hash), y 16384 ranuras se asignan de forma predeterminada
• Cada fragmento de datos se almacenará en varios nodos que son maestros y esclavos entre sí
• La escritura de datos se escribe primero en el nodo maestro y luego se sincroniza con el nodo esclavo (admite la configuración como sincronización de bloqueo)
• Los datos entre varios nodos en el mismo fragmento no son consistentes
• Al leer datos, cuando la clave de la operación del cliente no está asignada al nodo, redis devolverá la instrucción de dirección para apuntar al nodo correcto
• Al expandirse, es necesario migrar parte de los datos del nodo antiguo al nodo nuevo

En el modo de clúster, ¿cómo se abordan las claves de redis? ¿Cuáles son los algoritmos para el direccionamiento distribuido?

• algoritmo hash (reconstrucción de caché grande)
• Algoritmo hash consistente (migración automática de caché) + nodo virtual (equilibrio de carga automático)
• Algoritmo de ranura hash del clúster de Redis

¿Se perderán operaciones de escritura en el clúster de Redis?

Redis no garantiza una sólida coherencia de los datos, lo que significa que, en la práctica, el clúster puede perder operaciones de escritura en determinadas condiciones.
Las siguientes condiciones pueden provocar la pérdida de operaciones de escritura:

• La clave caducada se limpia
• La memoria máxima es insuficiente, lo que hace que Redis limpie automáticamente algunas claves para ahorrar espacio
• Reinicio automático después de la falla de la biblioteca principal, sincronización automática desde la biblioteca
• Esquema maestro-esclavo separado, la inestabilidad de la red activa el cambio automático de los nodos maestro y esclavo del centinela y la pérdida de datos durante el cambio.

¿Cuál es la cantidad máxima de nodos en un clúster de redis?

16,384

¿Cómo elegir una base de datos para el clúster de Redis?

El clúster de Redis actualmente no puede realizar la selección de la base de datos, el valor predeterminado es 0 base de datos.