Tabla de contenido
1. Replicación maestro-esclavo
2. Ventajas de la arquitectura maestro-esclavo en comparación con la arquitectura de punto único
3. Principio y flujo de trabajo de replicación maestro-esclavo
La primera etapa: establecer vínculos y negociar la sincronización
Fase 2: el servidor maestro sincroniza los datos con el servidor esclavo
Fase 3: el servidor maestro envía un nuevo comando de operación de escritura al servidor esclavo
Propagación de comandos basada en conexiones largas.
Comparte la presión en el servidor principal.
Esclavos con rol de "Administrador"
Editar el proceso de copia incremental
¿Cómo sabe el servidor maestro qué datos incrementales enviar al servidor esclavo?
Ajustar el búfer repl_backlog_buffer
4. Desventajas de la arquitectura maestro-esclavo
3. ¿Cómo determina Sentinel si un nodo está realmente defectuoso?
4. ¿Qué centinela realiza la conmutación por error maestro-esclavo?
5. Proceso de conmutación por error maestro-esclavo
Paso 1: seleccione un nuevo nodo maestro
Primera ronda de inspección: gana el nodo esclavo con mayor prioridad.
Segunda ronda de inspección: gana el nodo esclavo con el mayor progreso de replicación.
Tercera ronda de inspección: gana el nodo esclavo con el número de identificación más pequeño.
Paso 2: apuntar el nodo esclavo al nuevo nodo maestro
Paso 3: Notificar al cliente que el nodo maestro ha sido reemplazado
Paso 4: cambie el antiguo nodo maestro por un nodo esclavo
6. Cómo se forma el grupo Sentinel
7. ¿Cómo conoce el clúster Sentinel la información del nodo esclavo?
2. Características del modo clúster
3. Teoría de la partición de datos
①El nodo toma la partición restante
4. ¿Por qué el número máximo de ranuras en el clúster de Redis es 16384?
5. Ejecutar comandos en el clúster.
7. Error MOVIDO y error PREGUNTAR
La diferencia entre el error PREGUNTAR y el error MOVER
8. ¿Cómo garantiza Redis Cluser una alta disponibilidad?
Paso 1: seleccione un nuevo nodo maestro
Paso 2: Asigne la ranura del nodo maestro fuera de línea al nuevo nodo
Paso 3: Notificar al clúster que el nodo maestro ha sido reemplazado
Paso 4: cambie el antiguo nodo maestro por un nodo esclavo
1. Replicación maestro-esclavo
1. Información general
La replicación maestro-esclavo se refiere a copiar datos de un servidor Redis a otros servidores Redis. El primero se denomina nodo maestro y el segundo se denomina nodo esclavo.
- La replicación de datos es unidireccional , solo del nodo maestro al nodo esclavo.
- De forma predeterminada, cada servidor Redis es un nodo maestro, y un nodo maestro puede tener múltiples nodos esclavos (o ningún nodo esclavo). Un nodo esclavo también puede tener nodos esclavos , pero un nodo esclavo solo puede tener un nodo maestro.
- El nodo maestro puede escribir y leer y es el principal responsable de las operaciones de escritura, mientras que el nodo esclavo solo puede realizar operaciones de lectura.
- Una vez que se apaga el host, los datos del esclavo se pueden usar normalmente, es decir, aún se pueden leer, esperando que el host se reinicie y regrese.
2. Ventajas de la arquitectura maestro-esclavo en comparación con la arquitectura de punto único
- Redundancia de datos y alta disponibilidad: para evitar fallas en el servidor Redis en un solo punto, se preparan y conectan varios servidores entre sí. Copie varias copias de datos y guárdelas en diferentes servidores, conéctelas y asegúrese de que los datos estén sincronizados. Incluso si uno de los servidores falla, los otros servidores aún pueden continuar brindando servicios.
-
El equilibrio de carga mejora el rendimiento de lectura: basado en la replicación maestro-esclavo, combinado con la separación de lectura y escritura, el nodo maestro puede proporcionar servicios de escritura y los nodos esclavos pueden proporcionar servicios de lectura (es decir, al escribir datos de Redis, la aplicación se conecta al maestro nodo, y al leer datos de Redis, la aplicación Conectar nodos esclavos) para compartir la carga del servidor; especialmente en escenarios donde hay menos escritura y más lectura, compartir la carga de lectura a través de múltiples nodos esclavos puede aumentar en gran medida la concurrencia del servidor Redis.
3. Principio y flujo de trabajo de replicación maestro-esclavo
Primera sincronización
Cuando se inicie el servidor esclavo, realizará la primera sincronización con el servidor maestro. El primer proceso de sincronización entre los servidores maestro y esclavo se puede dividir en tres etapas:
- La primera etapa es establecer enlaces y negociar la sincronización;
- La segunda etapa es que el servidor maestro sincroniza los datos con el servidor esclavo;
- La tercera etapa es que el servidor maestro envía un nuevo comando de operación de escritura al servidor esclavo.
La primera etapa: establecer vínculos y negociar la sincronización
- Después de ejecutar el comando replicaof, el servidor esclavo enviará el comando psync al servidor maestro para indicar que se requiere sincronización de datos . El comando psync contiene dos parámetros, a saber, el ID de ejecución del servidor maestro y el desplazamiento del progreso de la replicación .
- Después de recibir el comando psync, el servidor principal utilizará FULLRESYNC como comando de respuesta para regresar con la otra parte. Y este comando de respuesta tomará dos parámetros: el ID de ejecución del servidor principal y el desplazamiento del progreso de replicación actual del servidor principal . Cuando se recibe la respuesta del servidor, se registran ambos valores.
El propósito del comando de respuesta FULLRESYNC es utilizar replicación completa , es decir, el servidor maestro sincronizará todos los datos con el servidor esclavo.
Fase 2: el servidor maestro sincroniza los datos con el servidor esclavo
- A continuación, el servidor maestro ejecuta el comando bgsave para generar el archivo RDB y luego envía el archivo al servidor esclavo.
- Después de recibir el archivo RDB del servidor, los datos actuales se borrarán primero y luego se cargará el archivo RDB.
Una cosa a tener en cuenta aquí es que el proceso de generación de RDB por parte del servidor principal no bloqueará el hilo principal , porque el comando bgsave genera un subproceso para generar el archivo RDB, que funciona de forma asincrónica, por lo que Redis aún puede procesar el comando. normalmente.
Sin embargo, los comandos de operación de escritura durante este período no se registran en el archivo RDB que se acaba de generar y los datos entre los servidores maestro y esclavo son inconsistentes. Para garantizar la coherencia de los datos de los servidores maestro y esclavo, el servidor maestro escribe los comandos de operación de escritura recibidos en el búfer de replicación en los siguientes tres intervalos de tiempo:
- Durante la generación de archivos RDB por parte del servidor principal;
- Durante el período en que el servidor maestro envía el archivo RDB al servidor esclavo;
- Durante la carga de archivos RDB "desde el servidor";
Fase 3: el servidor maestro envía un nuevo comando de operación de escritura al servidor esclavo
- Después de enviar el archivo RDB generado por el servidor maestro y el servidor esclavo recibe el archivo RDB, todos los datos antiguos se descartan y los datos RDB se cargan en la memoria. Una vez cargado el RDB, se enviará un mensaje de confirmación al servidor principal.
- Luego, el servidor maestro envía el comando de operación de escritura registrado en el búfer de replicación al servidor esclavo, y el servidor esclavo ejecuta el comando enviado desde el búfer de replicación del servidor maestro.En este momento, los datos de los servidores maestro y esclavo son consistentes.
En este punto, se completa la primera sincronización del servidor maestro-esclavo.
Propagación de comandos basada en conexiones largas.
Una vez que el servidor maestro-esclavo complete la primera sincronización, se mantendrá una conexión TCP entre las dos partes. Y esta conexión es una conexión a largo plazo, el propósito es evitar la sobrecarga de rendimiento causada por conexiones y desconexiones TCP frecuentes.
Posteriormente, el servidor maestro puede continuar propagando el comando de operación de escritura al servidor esclavo a través de esta conexión, y luego el servidor esclavo ejecuta el comando, haciendo que el estado de la base de datos del servidor maestro sea el mismo.
Redis utiliza el mecanismo de detección de mentalidad de ping-pong mutuo para determinar si los nodos están funcionando correctamente. Si más de la mitad de los nodos hacen ping a un nodo sin una respuesta pong, el clúster pensará que el nodo está inactivo y se desconectará del nodo. conectar.
Los intervalos enviados por los nodos maestro y esclavo de Redis son diferentes y sus funciones también son ligeramente diferentes:
- De forma predeterminada, el nodo maestro de Redis envía un comando de ping al nodo esclavo cada 10 segundos para determinar la supervivencia y el estado de conexión del nodo esclavo. La frecuencia de envío se puede controlar a través del parámetro repl-ping-slave-period.
- El nodo esclavo de Redis envía el comando replconf ack{offset} cada 1 segundo para informar su desplazamiento de replicación actual al nodo maestro para los siguientes propósitos:
- Monitoreo en tiempo real del estado de la red del nodo maestro-esclavo;
- Informe su propio desplazamiento de replicación y verifique si los datos de replicación se pierden. Si se pierden los datos del nodo esclavo, los datos perdidos se extraen del búfer de replicación del nodo maestro.
Comparte la presión en el servidor principal.
Introducción al problema
En el análisis anterior, podemos saber que durante el primer proceso de sincronización de datos entre los servidores maestro y esclavo, el servidor maestro realizará dos operaciones que requieren mucho tiempo: generar archivos RDB y transferir archivos RDB .
El servidor maestro puede tener varios servidores esclavos. Si hay muchos servidores esclavos y todos están completamente sincronizados con el servidor maestro, surgirán dos problemas:
- Dado que el archivo RDB se genera mediante el comando bgsave, el servidor principal estará ocupado usando fork() para crear procesos secundarios. Si los datos de la memoria del servidor principal no son grandes, el hilo principal se bloqueará cuando la función fork() se ejecuta, lo que hace que Redis no pueda manejar la solicitud normalmente;
- La transmisión de archivos RDB ocupará el ancho de banda de la red del servidor principal y afectará la respuesta del servidor principal a las solicitudes de comando.
Esta situación es como una empresa recién creada: como no hay muchos empleados, todos los empleados son administrados solo por el jefe. Sin embargo, a medida que la empresa se desarrolla y el número de empleados aumenta, el jefe gradualmente no podrá asumir la gestión. de todos los empleados.
Esclavos con rol de "Administrador"
Para resolver este problema, el jefe necesita establecer un puesto de gerente, donde el gerente administra a varios empleados ordinarios, y luego el jefe solo necesita administrar al gerente.
Lo mismo ocurre con Redis. El servidor esclavo puede tener su propio servidor esclavo . Podemos considerar el servidor esclavo con el servidor esclavo como la función de administrador. No solo puede recibir los datos de sincronización del servidor maestro, sino también sincronizar los datos. como servidor maestro al mismo tiempo al servidor esclavo, pero aún no puede realizar operaciones de escritura . La organización es la siguiente:
De esta manera, la presión de generar y transmitir RDB en el servidor maestro se puede descargar al servidor esclavo que actúa como administrador .
copia incremental
Introducción al problema
Una vez que el servidor maestro-esclavo complete la primera sincronización, propagará comandos basados en conexiones largas. Si se desconecta la conexión de red entre los servidores maestro y esclavo, los comandos no se pueden propagar. En este momento, los datos en el servidor esclavo no pueden ser consistentes con el servidor maestro y el cliente puede leer datos antiguos del "servidor esclavo". .
- Antes de Redis 2.8, si la red se desconectaba y restauraba entre los servidores maestro y esclavo durante la sincronización de comandos, el servidor esclavo realizaría una replicación completa con el servidor maestro nuevamente. Obviamente, esta sobrecarga era demasiado grande y se deben realizar mejoras.
- Por lo tanto, a partir de Redis 2.8, después de desconectar y restaurar la red, los servidores esclavo maestro y esclavo continuarán sincronizándose mediante replicación incremental , es decir, solo los comandos de operación de escritura recibidos por el servidor maestro durante la desconexión de la red se sincronizarán con el servidor esclavo. .
El proceso de copia incremental después de la recuperación de la red es el siguiente:
Proceso de copia incremental
- Después de que el servidor esclavo restaure la red, enviará el comando psync al servidor maestro. En este momento, el parámetro de desplazamiento en el comando psync no es -1 ;
- Después de recibir el comando, el servidor maestro usa el comando de respuesta CONTINUAR para indicarle al servidor esclavo que use la replicación incremental para sincronizar los datos;
- Luego, el servicio maestro envía los comandos de escritura ejecutados durante la desconexión de los servidores maestro y esclavo al servidor esclavo, y luego el servidor esclavo ejecuta estos comandos.
¿Cómo sabe el servidor maestro qué datos incrementales enviar al servidor esclavo?
La respuesta está en estas dos cosas:
- repl_backlog_buffer: es un búfer de " anillo ", que se utiliza para encontrar datos diferenciales después de que se desconecta el servidor maestro-esclavo; cuando el servidor maestro propaga comandos, no solo enviará el comando de escritura al servidor esclavo, sino que también escribirá el comando de escritura en servidor esclavo al búfer repl_backlog_buffer, por lo que este búfer contendrá el comando de escritura propagado más recientemente.
- Desplazamiento de replicación: marque el progreso de sincronización del búfer anterior. Los servidores maestro y esclavo tienen sus propios desplazamientos. El servidor maestro usa master_repl_offset para registrar la posición que "escribe" y el servidor esclavo usa Slave_repl_offset para registrar la posición que "lee". . .
Después de desconectar la red, cuando el servidor esclavo se vuelve a conectar al servidor maestro, el servidor esclavo enviará su propio desplazamiento de replicación esclavo_repl_offset al servidor maestro a través del comando psync. El servidor maestro luego decidirá en función de la brecha entre su propio master_repl_offset y Slave_repl_offset.Qué operación de sincronización se realiza en el servidor esclavo:
- Si se determina que los datos que se leerán del servidor esclavo todavía están en el búfer repl_backlog_buffer, entonces el servidor maestro utilizará sincronización incremental ;
- Por el contrario, si se determina que los datos que se leerán del servidor esclavo ya no existen en el búfer repl_backlog_buffer, entonces el servidor maestro utilizará la sincronización completa .
Cuando el servidor maestro encuentra los datos de diferencia (incrementales) entre los servidores maestro y esclavo en repl_backlog_buffer, escribirá los datos incrementales en el búfer de replicación . También mencionamos este búfer antes. Es el caché que se propagará al esclavo. Comandos del servidor.
El tamaño predeterminado del búfer de caché repl_backlog_buffer es 1 M y, dado que es un búfer en anillo, cuando el búfer está lleno, si el servidor principal continúa escribiendo, los datos anteriores se sobrescribirán. Por lo tanto, cuando la velocidad de escritura del servidor maestro excede con creces la velocidad de lectura del servidor esclavo, los datos en el búfer se sobrescribirán de inmediato.
Por lo tanto, para evitar que el servidor principal utilice con frecuencia la sincronización completa cuando se restaura la red, debemos ajustar el tamaño del búfer repl_backlog_buffer para que sea lo más grande posible para reducir la probabilidad de que se sobrescriban los datos que se leerán desde el servidor esclavo . para que el servidor principal utilice sincronización incremental.
Ajustar el búfer repl_backlog_buffer
El tamaño mínimo de repl_backlog_buffer se puede estimar según esta fórmula.
- segundo es el tiempo promedio (en segundos) requerido para volver a conectarse al servidor maestro después de que se desconecta el servidor esclavo.
- write_size_per_segundo es la cantidad promedio de datos de comando de escritura generados por el servidor principal por segundo.
Por ejemplo, si el servidor principal genera un promedio de 1 MB de comandos de escritura por segundo y se necesitan un promedio de 5 segundos para volver a conectarse al servidor principal después de que se desconecta el servidor secundario. Entonces, el tamaño de repl_backlog_buffer no puede ser inferior a 5 MB; de lo contrario, el nuevo comando de escritura sobrescribirá los datos antiguos.
Por supuesto, para hacer frente a algunas emergencias, el tamaño de repl_backlog_buffer se puede establecer en 2 veces esta base, que es 10 MB.
4. Desventajas de la arquitectura maestro-esclavo
En la arquitectura maestro-esclavo de Redis, dado que el modo maestro-esclavo separa la lectura y la escritura, si el nodo maestro (maestro) cuelga, no habrá ningún nodo maestro para atender la solicitud de operación de escritura del cliente y no habrá ningún maestro. nodo para proporcionar nodos esclavos (esclavo) Se realiza la sincronización de datos.
Si desea restaurar el servicio en este momento, debe intervenir manualmente , seleccionar un "nodo esclavo" para cambiar al "nodo maestro" y luego dejar que otros nodos esclavos apunten al nuevo nodo maestro. También debe notificar a los clientes ascendentes conectados al nodo maestro de Redis y actualizar la dirección IP del nodo maestro en su configuración a la dirección IP del "nuevo nodo maestro".
2. Mecanismo centinela
1. Concepto
En la arquitectura maestro-esclavo de Redis, si el nodo maestro (maestro) cuelga, se requiere intervención manual. Por lo tanto, necesitamos un nodo que pueda monitorear el estado del "nodo maestro"; cuando se descubre que el nodo maestro está inactivo, puede cambiar automáticamente un "nodo esclavo" a un "nodo maestro" según el número de votos. Y notificar la información relevante del nuevo nodo maestro a Del nodo y al cliente , este es el mecanismo centinela.
2. El papel de los centinelas
- Monitoreo maestro-esclavo: monitoree si la biblioteca redis maestro-esclavo se está ejecutando normalmente
- Conmutación por error: si el maestro es anormal, se realizará un cambio maestro-esclavo y uno de los esclavos se utilizará como nuevo maestro.
- Notificación de mensaje: Sentinel puede enviar los resultados de la conmutación por error al cliente
- Centro de configuración: el cliente obtiene la dirección del nodo maestro del servicio Redis actual conectándose a Sentinel
Nota: Sentinel solo monitorea y mantiene el clúster y no almacena datos.
3. ¿Cómo determina Sentinel si un nodo está realmente defectuoso?
Sentinel enviará comandos PING a todos los nodos maestro y esclavo cada 1 segundo. Cuando los nodos maestro y esclavo reciban el comando PING, enviarán un comando de respuesta a Sentinel para que puedan juzgar si se están ejecutando normalmente.
Si el nodo maestro o el nodo esclavo no responde al comando PING de Sentinel dentro del tiempo especificado, Sentinel los marcará como " subjetivamente fuera de línea " . Este "tiempo prescrito" se establece mediante el parámetro de inactividad después de milisegundos del elemento de configuración, y la unidad es milisegundos.
Subjetivo fuera de línea
" Subjetivo fuera de línea " es para un solo centinela . Debido a la congestión de la red y otras razones, es probable que se produzcan errores de juicio. Por lo tanto, para reducir los errores de juicio, el centinela no implementará solo un nodo durante la implementación, sino que utilizará varios nodos. nodos en un clúster centinela (se requieren al menos tres máquinas para implementar un clúster centinela). Al juzgar varios nodos centinela juntos, puede evitar la situación en la que un solo centinela determina erróneamente que el nodo maestro está fuera de línea debido a malas condiciones de la red. Al mismo tiempo, la probabilidad de que varias redes centinela sean inestables al mismo tiempo es pequeña y, si toman decisiones juntas, la tasa de errores de juicio también se puede reducir.
Objetivo fuera de línea
Donde hay subjetividad, hay objetividad. Cuando un centinela determina que el nodo maestro está "subjetivamente fuera de línea", emitirá un comando a otros centinelas. Después de recibir este comando, los otros centinelas llegarán a un acuerdo basado en las condiciones de la red de ellos mismos y el nodo maestro Una respuesta para votar o rechazar un voto .
Cuando el número de votos de aprobación de este centinela alcanza el valor establecido por el elemento de configuración del quórum en el archivo de configuración de centinela , el centinela marcará el nodo maestro como "objetivamente fuera de línea" .
Por ejemplo, actualmente hay 3 centinelas y la configuración del quórum es 2. Luego, un centinela necesita 2 votos de aprobación para marcar el nodo maestro como "objetivo fuera de línea". Estos 2 votos afirmativos incluyen uno del propio centinela y los votos afirmativos de otros dos centinelas.
Nota: El valor del quórum generalmente se establece en la mitad del número de centinelas más 1. Por ejemplo, si hay 3 centinelas, establezca 2. Y el número de ganglios centinela debe ser impar.
Después de que Sentinel determine que el nodo maestro está objetivamente fuera de línea, Sentinel comenzará a seleccionar un nodo esclavo entre múltiples "nodos esclavos" para que sea el nuevo nodo maestro.
4. ¿Qué centinela realiza la conmutación por error maestro-esclavo?
Mencionamos antes que si se utiliza el mecanismo centinela, se debe implementar un clúster centinela , entonces, cuando el maestro falla, ¿quién realizará la conmutación por error maestro-esclavo? ¿Quieres ir juntos? Obviamente no.
Cuando se considera que el nodo maestro está objetivamente fuera de línea, cada nodo centinela negociará para elegir un nodo centinela líder y el nodo líder realizará una conmutación por error (migración fallida).
quienes son los candidatos
Qué nodo centinela determina que el nodo maestro está "objetivamente fuera de línea" . Este nodo centinela es el candidato y el llamado candidato es el centinela que quiere ser el líder.
Por ejemplo, supongamos que hay tres centinelas. Cuando Sentinel B determina por primera vez que el nodo maestro está "subjetivamente fuera de línea", enviará el comando is-master-down-by-addr a otras instancias. Luego, otros centinelas responderán aceptando votar o rechazando el voto según su conexión de red con el nodo maestro.
Cuando el número de votos de aprobación recibidos por Sentinel B alcanza el valor establecido por el elemento de configuración del quórum en el archivo de configuración de Sentinel, el nodo maestro se marcará como "objetivamente fuera de línea". En este momento, Sentinel B es un candidato a líder.
Cómo seleccionar líder
El candidato enviará un comando a otros centinelas indicando que quiere convertirse en el líder para realizar el cambio maestro-esclavo y dejará que todos los demás centinelas voten al respecto. El algoritmo utilizado en la elección es el algoritmo Raft, la idea básica del algoritmo Raft es por orden de llegada: es decir , en una ronda de elecciones, Sentinel B envía una solicitud para convertirse en líder a A. Si A Si no ha aceptado a otros centinelas, aceptará que B se convierta en el líder.
Cada centinela tiene sólo una oportunidad de votar, si se agota no puede participar en la votación, puede votar por sí mismo o por otros, pero sólo el candidato puede votar por sí mismo.
Durante el proceso de votación, cualquier "candidato" debe cumplir dos condiciones para ser elegido Líder :
- Primero, conseguir más de la mitad de los votos a favor;
- En segundo lugar, la cantidad de votos recibidos debe ser mayor o igual que el valor de quórum en el archivo de configuración centinela.
Por ejemplo, suponiendo que hay 3 nodos centinela y el quórum es 2, cualquier centinela que quiera convertirse en líder puede ser elegido exitosamente siempre que obtenga 2 votos a favor. Si no se cumplen las condiciones, será necesario celebrar nuevas elecciones.
Si en un momento determinado hay exactamente dos nodos centinela que determinan que el nodo maestro está objetivamente fuera de línea, cada candidato primero votará por sí mismo y luego iniciará una solicitud de votación a otros centinelas. Si el elector recibe primero una solicitud de voto del "Candidato A", votará primero por ella. Si el elector agota su oportunidad de votar y recibe una solicitud de voto del "Candidato B", se negará a votar. En este momento, el candidato A cumple por primera vez las dos condiciones anteriores, por lo que el "candidato A" será elegido líder.
5. Proceso de conmutación por error maestro-esclavo
Una vez que se elige al líder de Sentinel mediante votación en el clúster de Sentinel, se puede llevar a cabo el proceso de conmutación por error maestro-esclavo, como se muestra en la siguiente figura:
La operación de conmutación por error maestro-esclavo consta de los siguientes cuatro pasos:
- Paso 1: Seleccione un nodo esclavo de todos los "nodos esclavos" bajo el nodo maestro fuera de línea (nodo maestro antiguo) y conviértalo en el nodo maestro.
- Paso 2: Deje que todos los "nodos esclavos" bajo el nodo maestro fuera de línea modifiquen el objetivo de replicación para copiar el "nuevo nodo maestro";
- Paso 3: Notificar al cliente la dirección IP y la información del nuevo nodo maestro a través del "mecanismo de editor/suscriptor";
- Paso 4: Continúe monitoreando el antiguo nodo maestro. Cuando el antiguo nodo maestro vuelva a estar en línea, configúrelo como el nodo esclavo del nuevo nodo maestro;
Paso 1: seleccione un nuevo nodo maestro
El primer paso en la operación de conmutación por error es seleccionar un nodo esclavo con buen estado y datos completos entre todos los "nodos esclavos" bajo el nodo maestro fuera de línea, y luego enviar el comando SLAVEOF no one a este "nodo esclavo", convertir esto " "nodo esclavo" en un "nodo maestro".
El proceso de selección es el siguiente:
- Primera ronda de inspección: Sentinel primero clasificará los nodos esclavos según su prioridad: cuanto menor sea la prioridad, mayor será la clasificación.
- Segunda ronda de inspección: si las prioridades son las mismas, verifique los subíndices de replicación. El que reciba más datos de replicación del "nodo maestro" ocupará el primer lugar.
- Tercera ronda de inspección: si la prioridad y el subíndice son los mismos, seleccione el nodo esclavo con la ID más pequeña.
Primera ronda de inspección: gana el nodo esclavo con mayor prioridad.
Redis tiene un elemento de configuración llamado prioridad de esclavo, que puede establecer la prioridad del nodo esclavo. La configuración del servidor de cada nodo esclavo no es necesariamente la misma, podemos establecer la prioridad del nodo esclavo de acuerdo con la configuración de rendimiento del servidor.
Por ejemplo, si la memoria física de "Un nodo esclavo" es la más grande entre todos los nodos esclavos, entonces podemos establecer la prioridad de "Un nodo esclavo" en la más alta. De esta manera, cuando el centinela realiza la primera ronda de consideración, el nodo esclavo A con mayor prioridad ganará primero y se convertirá en el nuevo nodo maestro.
Segunda ronda de inspección: gana el nodo esclavo con el mayor progreso de replicación.
Si en la primera ronda de inspección se encuentra que hay dos nodos esclavos con la mayor prioridad, se llevará a cabo una segunda ronda de inspección para comparar el progreso de replicación de los dos nodos esclavos.
Mencionamos el progreso de la replicación antes cuando hablamos de la arquitectura maestro-esclavo: en la arquitectura maestro-esclavo, el nodo maestro sincronizará la operación de escritura con el nodo esclavo. En este proceso, el nodo maestro usará master_repl_offset para registrar la última escritura. operación en repl_backlog_buffer ( la posición de "los datos que el servidor maestro ha escrito" en la figura a continuación), y el nodo esclavo usará el valor esclavo_repl_offset para registrar el progreso de replicación actual (la posición de "la posición donde el servidor esclavo quiere leer" en la figura siguiente).
Si el Slave_repl_offset de un nodo esclavo es el más cercano al master_repl_offset, significa que su progreso de replicación es el más alto, por lo que puede seleccionarse como el nuevo nodo maestro.
Tercera ronda de inspección: gana el nodo esclavo con el número de identificación más pequeño.
Si en la segunda ronda de inspección se encuentra que dos nodos esclavos tienen la misma prioridad y progreso de replicación, entonces se llevará a cabo la tercera ronda de inspección para comparar los números de identificación de los dos nodos esclavos. Identifica de forma única el nodo esclavo. Para los nodos, gana el nodo esclavo con el número de identificación más pequeño.
Después de elegir el nodo esclavo, el líder centinela envía el comando SLAVEOF no one al nodo esclavo seleccionado para permitir que el nodo esclavo libere su estado como nodo esclavo y lo convierta en el nuevo nodo maestro. Como se muestra en la figura siguiente, el líder centinela envía el comando SLAVEOF no one al servidor2 del nodo esclavo seleccionado para actualizar el nodo esclavo al nuevo nodo maestro.
Después de enviar el comando SLAVEOF no one , el líder centinela enviará el comando INFO al nodo esclavo actualizado una vez por segundo ( antes de la conmutación por error, la frecuencia del comando INFO es una vez cada diez segundos ) y observará la respuesta del comando. cuando la información de función del nodo actualizado cambia del esclavo original al maestro, el líder centinela sabrá que el nodo esclavo seleccionado se ha actualizado exitosamente al nodo maestro.
Como se muestra en la siguiente figura, el servidor2 del nodo esclavo seleccionado se actualiza al nuevo nodo maestro:
Paso 2: apuntar el nodo esclavo al nuevo nodo maestro
Cuando aparece el nuevo nodo maestro, el siguiente paso del líder centinela es hacer que todos los "nodos esclavos" bajo el nodo maestro fuera de línea apunten al "nuevo nodo maestro". Esta acción se puede realizar enviando el comando SLAVEOF al " nodos esclavos" para cumplir.
Como se muestra en la figura siguiente, el líder centinela envía SLAVEOF a todos los nodos esclavos (servidor3 y servidor4), lo que les permite convertirse en nodos esclavos del nuevo nodo maestro.
Paso 3: Notificar al cliente que el nodo maestro ha sido reemplazado
Después de la serie anterior de operaciones, el clúster Sentinel finalmente completó el cambio maestro-esclavo. Entonces, ¿cómo se notifica al cliente la información sobre el nuevo nodo maestro?
Esto se logra principalmente a través del mecanismo de editor/suscriptor de Redis . Cada nodo centinela proporciona un mecanismo de editor/suscriptor, y los clientes pueden suscribirse a los mensajes del centinela. Sentinel proporciona muchos canales de suscripción de mensajes. Cada canal contiene diferentes eventos clave en el proceso de conmutación del nodo maestro-esclavo. Varios eventos comunes son los siguientes:
Una vez que el cliente establece una conexión con Sentinel, se suscribirá al canal proporcionado por Sentinel. Una vez completado el cambio maestro-esclavo, Sentinel publicará la dirección IP y el mensaje de puerto del nuevo nodo maestro en el canal + switch-master. En este momento, el cliente puede recibir este mensaje y luego usar la dirección IP del nuevo Nodo maestro Comunicado con el puerto.
A través del mecanismo de editor/suscriptor, con estas notificaciones de eventos, el cliente no solo puede obtener la información de conexión del nuevo nodo maestro después del cambio maestro-esclavo, sino también monitorear varios eventos importantes que ocurren durante el cambio del nodo maestro-esclavo. De esta manera, el cliente puede saber en qué paso se encuentra el cambio maestro-esclavo, lo que ayuda a comprender el progreso del cambio.
Paso 4: cambie el antiguo nodo maestro por un nodo esclavo
Lo último que debe hacer en la operación de conmutación por error es continuar monitoreando el antiguo nodo maestro. Cuando el antiguo nodo maestro vuelva a estar en línea, el clúster Sentinel le enviará el comando SLAVEOF para convertirlo en el nodo esclavo del nuevo nodo maestro, como mostrado a continuación:
En este punto, se completa la conmutación por error de todo el nodo maestro-esclavo.
6. Cómo se forma el grupo Sentinel
De hecho, cuando configuramos la información centinela, solo necesitamos completar los siguientes parámetros: configurar el nombre del nodo maestro, la dirección IP y el número de puerto del nodo maestro y el valor de quórum.
sentinel monitor <master-name> <ip> <redis-port> <quorum>
No es necesario completar la información de otros ganglios centinela ¿Cómo se perciben entre sí?
De hecho, también se descubren entre sí a través del mecanismo de editor/suscriptor de Redis . En el clúster maestro-esclavo, hay un canal llamado __sentinel__:hello en el nodo maestro, a través del cual diferentes centinelas se descubren y se comunican entre sí.
En la siguiente figura, Sentinel A publica su dirección IP e información de puerto en el canal __sentinel__:hello, y los Sentinels B y C se suscriben a este canal. En este momento, Sentinel B y C pueden obtener directamente la dirección IP y el número de puerto de Sentinel A de este canal. Luego, los Sentinels B y C pueden establecer conexiones de red con Sentinel A.
De esta manera, los Sentinels B y C también pueden establecer conexiones de red, de modo que se forme un clúster Sentinel.
7. ¿Cómo conoce el clúster Sentinel la información del nodo esclavo?
El nodo maestro conoce la información de todos los "nodos esclavos", por lo que el centinela enviará un comando INFO al nodo maestro cada 10 segundos para obtener la información de todos los "nodos esclavos".
Como se muestra en la figura siguiente, Sentinel B envía un comando INFO al nodo maestro. Después de recibir este comando, el nodo maestro devuelve la lista de nodos esclavos a Sentinel . Luego, el centinela puede establecer una conexión con cada nodo esclavo en función de la información de conexión en la lista de nodos esclavos y monitorear continuamente el nodo esclavo en esta conexión . Los centinelas A y C pueden establecer conexiones con nodos esclavos mediante el mismo método.
A través del mecanismo de editor / suscriptor de Redis , los centinelas pueden percibirse entre sí y formar un grupo. Al mismo tiempo, los centinelas obtienen toda la información de conexión del nodo esclavo en el nodo maestro a través del comando INFO, para que puedan establecer conexiones con el esclavo. nodos y monitoreados.
3. Fragmentación de clústeres
1. Introducción al problema
El modo Sentinel resuelve los problemas de alta disponibilidad y alta lectura concurrente, pero aún tiene desventajas:
- En modo centinela, cada servidor Redis almacena los mismos datos, lo que desperdicia memoria y dificulta el almacenamiento de datos masivos.
- Solo hay un Maestro en modo centinela, lo que dificulta admitir escrituras concurrentes elevadas.
Esto llevó al modo de clúster.
2. Características del modo clúster
- El clúster de Redis admite múltiples maestros, cada maestro puede montar múltiples esclavos y cada maestro guarda datos diferentes.
- Los maestros detectan el estado de salud de los demás mediante ping, se eligen entre sí y ya no dependen del centinela.
- Cuando el cliente se conecta al nodo de Redis, ya no necesita conectarse a todos los nodos del clúster, solo necesita conectarse a cualquier nodo disponible en el clúster, porque eventualmente se reenviará al nodo correcto .
Nota: La forma en que los nodos del clúster guardan los pares clave-valor y el tiempo de vencimiento del par clave-valor es la misma que el modo independiente de Redis. La única diferencia es que los nodos solo pueden usar la base de datos número 0, mientras que los servidores Redis independientes no tienen restricciones.
3. Teoría de la partición de datos
①El nodo toma la partición restante
Cada operación de lectura y escritura realizada por el usuario se basa en la fórmula: hash (clave) % N número de máquinas, y el valor hash se calcula para determinar a qué nodo se asignan los datos.
Hay un problema con esta solución: cuando cambia el número de nodos, como expandir o reducir los nodos, es necesario volver a calcular la relación de mapeo de los nodos de datos, lo que provocará una nueva migración de datos y todos los cachés dejarán de ser válidos.
② Partición Hash consistente
No entraré en detalles aquí. Recomiendo ver el vídeo del profesor Hao Gang, habla muy bien.
③Partición de ranura hash
El clúster de Redis no utiliza hash consistente, pero introduce el concepto de ranuras hash .
La ranura hash (ranura) se encuentra entre los datos y el nodo y se utiliza para gestionar la relación entre los datos y el nodo.Es equivalente a colocar una ranura en el nodo y colocar datos en la ranura.
Las ranuras resuelven el problema de la granularidad , lo que equivale a aumentar la granularidad, lo que facilita el movimiento de datos. Hash resuelve el problema de mapeo: el valor hash de la clave se utiliza para calcular la ranura, lo que facilita la distribución de datos.
El clúster de Redis tiene 16384 ranuras hash. Primero calcule el valor hash CRC16 de cada clave y luego tome el módulo 16384 para determinar en qué ranura colocarlo. Cada nodo del clúster es responsable de una parte de las ranuras hash. Por ejemplo, si el clúster actual tiene 3 nodos, entonces:
4. ¿Por qué el número máximo de ranuras en el clúster de Redis es 16384?
El valor hash generado por el algoritmo CRC16 es de 16 bits y este algoritmo puede generar 2 ^ 16 = 65536 valores. En otras palabras, los valores se distribuyen entre 0 y 65535. Si hay un valor mayor de 65536, ¿por qué solo 16384 es suficiente? Cuando el autor estaba realizando la operación mod, ¿por qué no mod65536 en lugar de mod16384?
Los nodos del clúster de Redis enviarán mensajes de ping según las siguientes reglas:
- Se seleccionarán aleatoriamente 5 nodos cada segundo, y se encontrará el nodo que no haya tenido comunicación durante más tiempo y se le enviará un mensaje de ping.
- La lista de nodos locales se escaneará cada 100 milisegundos. Si se descubre que la última vez que el nodo recibió un mensaje pong es mayor que el tiempo de espera del nodo del clúster/2, se enviará un mensaje de ping inmediatamente.
Hay una matriz de caracteres de myslots en el encabezado del mensaje del paquete de latidos , que es un mapa de bits . Cada bit representa una ranura . Si el bit es 1, significa que la ranura pertenece a este nodo.
(1) Si la ranura es 65536, el encabezado del mensaje para enviar información de latidos alcanza los 8k y el paquete de latidos enviado es demasiado grande, lo que desperdicia ancho de banda.
- El que ocupa más espacio en el encabezado del mensaje es myslots[CLUSTER_SLOTS/8]. Cuando el slot es 65536, el tamaño de este bloque es: 65536÷8÷1024=8kb
- El que ocupa más espacio en el encabezado del mensaje es myslots[CLUSTER_SLOTS/8]. Cuando la ranura es 16384, el tamaño de este bloque es: 16384÷8÷1024=2kb
(2) Es básicamente imposible que el número de nodos maestros del clúster de Redis supere los 1000. Demasiados pueden causar congestión en la red.
Cuantos más nodos del clúster haya, más datos se transportarán en el cuerpo del mensaje del paquete de latidos . Si hay más de 1000 nodos, también provocará congestión en la red . Por lo tanto, el autor de Redis no recomienda que el número de nodos del clúster de Redis supere los 1000. Entonces, para un clúster de Redis con menos de 1000 nodos, 16384 ranuras son suficientes. No es necesario ampliar a 65536.
(3) Cuanto más pequeña sea la ranura, mayor será la relación de compresión y más fácil la transmisión.
En la información de configuración del nodo maestro de Redis, la ranura hash de la que es responsable se guarda en forma de mapa de bits . El mapa de bits se comprimirá durante el proceso de transmisión . La tasa de llenado del mapa de bits (ranuras/N, N representa el número de nodos) es mayor.Bajo, mayor es la relación de compresión. Entonces, cuanto menor sea el número de ranuras, la tasa de llenado disminuirá y la tasa de compresión aumentará.
5. Ejecutar comandos en el clúster.
Después de asignar todas las 16384 ranuras en la base de datos, el clúster entrará en el estado en línea. Aquí es cuando el cliente puede enviar comandos de datos a los nodos del clúster. Necesita calcular a qué ranura pertenece la clave que será procesada por el comando. Y compruebe si está asignado a usted mismo.
Si la ranura donde se encuentra la clave está asignada al nodo actual, entonces el nodo ejecuta directamente este comando:
Si la ranura donde se encuentra la clave no está asignada al nodo actual, el nodo devolverá un error MOVED al cliente (en modo clúster, el error MOVED está oculto y no se mostrará, pero se mostrará directamente como Redirigido) para guiar al cliente Redirija al nodo correcto y envíe el comando que desea ejecutar nuevamente.
6.Reasignar espacios
Cuando el clúster de Redis se expande o reduce, las ranuras se reasignarán.
- La operación de reasignación de espacios del clúster de Redis puede cambiar cualquier número de espacios que se hayan asignado a un nodo a otro nodo (nodo de destino), y los pares clave-valor a los que pertenecen los espacios relevantes también se moverán del nodo de origen al de destino. nodo superior.
- La operación de fragmentación se puede realizar en línea. Durante el proceso de fragmentación, no es necesario que el clúster esté fuera de línea y tanto el nodo de origen como el nodo de destino pueden continuar procesando solicitudes de comando.
- La redistribución de ranuras en el clúster de Redis se realiza mediante el software de administración de clústeres redis-trib . Redis proporciona todos los comandos necesarios para la resharding.redis-trib reshards enviando comandos al nodo de origen y al nodo de destino.operar.
7. Error MOVIDO y error PREGUNTAR
error MOVIDO
Como se mencionó anteriormente, si la ranura donde se encuentra la clave no está asignada al nodo actual, el nodo devolverá un error MOVED al cliente (que estará oculto).
El formato de un error MOVED es:
MOVED <slot> <ip>:<port>
Donde slot es el slot donde se encuentra la clave, e ip y port son la dirección IP y el número de puerto del nodo responsable de procesar el slot.
# 表示槽10086正由127.0.0.1，端口号为7002的节点负责。
MOVED 10086 127.0.0.1:7002Un cliente de clúster generalmente crea conexiones de socket con múltiples nodos en el clúster , y la llamada dirección de nodo en realidad significa cambiar un socket para enviar comandos .
Si el cliente aún no ha establecido una conexión de socket con el nodo que desea redirigir, el cliente primero se conectará al nodo según la dirección IP y el número de puerto proporcionados por el error MOVED, y luego redirigirá .
PREGUNTAR error
Durante la resharding, cuando el nodo de origen migra una ranura al nodo de destino, puede ocurrir una situación: parte de los pares clave-valor que pertenecen a la ranura migrada se guardan en el nodo de origen, mientras que otra parte de los pares clave-valor se guardan en el nodo de origen dentro del nodo de destino.
Cuando el cliente envía un comando relacionado con una clave de base de datos al nodo de origen, y la clave de la base de datos que será procesada por el comando pertenece a la ranura que se está migrando :
- El nodo de origen primero buscará la clave especificada en su propia base de datos y, si la encuentra, ejecutará directamente el comando enviado por el cliente.
- Por el contrario, si el nodo de origen no puede encontrar la clave especificada en su propia base de datos, es posible que la clave se haya migrado al nodo de destino y el nodo de origen devolverá un error PREGUNTAR (también oculto) al cliente para guiarlo. Vaya al nodo de destino donde se está importando la ranura y envíe el comando que desea ejecutar nuevamente.
De manera similar a la situación cuando se recibe un error MOVED, redis-cli en modo clúster no imprimirá un error cuando se recibe un error ASK, pero realizará automáticamente acciones de redirección basadas en la dirección IP y el puerto proporcionados por el error.
La diferencia entre el error PREGUNTAR y el error MOVER
- Un error MOVED indica que la responsabilidad del slot se ha transferido de un nodo a otro.
- El error ASK indica la responsabilidad de los dos nodos por el procesamiento de claves durante el proceso de ranura de migración.
8. ¿Cómo garantiza Redis Cluser una alta disponibilidad?
Redis Cluster se basa principalmente en dos estrategias para garantizar una alta disponibilidad: detección de fallas y conmutación por error. De hecho, el procesamiento de estas dos estrategias es similar al procesamiento del modo centinela.
Detección de fallas
Cada nodo del clúster enviará periódicamente mensajes PING a otros nodos del clúster para detectar si el otro nodo está en línea; si el nodo que recibe el mensaje PING no devuelve un mensaje PONG al nodo que envía el mensaje PING dentro del tiempo especificado, luego envíe El nodo que recibe el mensaje PING marcará el nodo del mensaje PING como sospechoso de estar fuera de línea (posible error, PFAIL) .
Si más de la mitad de los nodos maestros responsables de procesar las ranuras en el clúster marcan un determinado nodo X como PFAIL, entonces un determinado nodo maestro marcará el nodo maestro X como fuera de línea (FAIL) y lo transmitirá a este mensaje, de modo que todos los demás nodos marcará inmediatamente el nodo maestro X como FALLO.
Supuestos:
- Redis Cluster tiene cuatro nodos maestros: 7000-7003 y dos nodos esclavos: 7004 y 7005
- En este momento, 7000 ha estado fuera de línea y el nodo maestro 7001 piensa que el nodo maestro 7000 ha ingresado a PFAIL.
- Al mismo tiempo, los nodos maestros 7002 y 7003 también creen que el nodo maestro 7000 ha entrado en estado fuera de línea.
De esta manera, más de la mitad de los nodos maestros piensan que el nodo 7000 ha fallado, luego 7001 marcará 7000 como estado FALLO y transmitirá el mensaje de que el nodo maestro 7000 ha FALLADO al clúster.
conmutación por error
Paso 1: seleccione un nuevo nodo maestro
- Entre todos los nodos esclavos del nodo maestro fuera de línea, seleccione uno como nodo maestro. El método de elección aquí también es similar al de Sentinel.
- El nodo esclavo seleccionado ejecutará el comando SLAVEOF no one y se convertirá en el nuevo nodo maestro;
Paso 2: Asigne la ranura del nodo maestro fuera de línea al nuevo nodo
El nuevo nodo maestro revocará todas las asignaciones de espacios al nodo maestro fuera de línea y se asignará todos los espacios a sí mismo.
Paso 3: Notificar al clúster que el nodo maestro ha sido reemplazado
El nuevo nodo maestro transmite un mensaje PONG al clúster para informar a otros nodos que "me he convertido en el nodo maestro y me haré cargo de las ranuras de procesamiento responsables de los nodos fuera de línea";
El nuevo nodo maestro comienza a recibir solicitudes de comando relacionadas con las ranuras que es responsable de procesar.
Paso 4: cambie el antiguo nodo maestro por un nodo esclavo
Por ejemplo: en un clúster que contiene cuatro nodos maestros 7000, 7001, 7002 y 7003, ahora agregamos dos nodos 7004 y 7005 y servimos como dos nodos esclavos del nodo maestro 7000.
Si el nodo maestro 7000 se desconecta (tiempo de inactividad) en este momento, todavía hay varios nodos maestros en el clúster. Uno de los dos nodos esclavos 7004 y 7005 del nodo 7000 se seleccionará como nodo maestro. Por ejemplo, si se selecciona 7004 , este nuevo nodo Tomará el espacio procesado por el nodo original 7000 y continuará procesando las solicitudes enviadas por el cliente, mientras que 7005 sirve como nodo esclavo de 7004 en este momento.
Si el nodo 7000 se desconecta y vuelve a conectarse, servirá como nodo esclavo del nodo 7004.
