Alta confiabilidad de Redis: 1: Garantizar la menor pérdida de datos posible; (AOF y RDB garantizan la menor pérdida de datos posible) 2: Interrupción del servicio lo menor posible. (Se debe lograr la menor interrupción del servicio agregando redundancia, guardando una copia de los datos en varias instancias. Si una instancia falla, llevará tiempo recuperarla y el resto de las instancias también se pueden usar sin esperar).

¿Qué es la alta disponibilidad?

Alta disponibilidad: Trate de no perder datos y brinde todos los servicios tanto como sea posible.

1. Principio de sincronización de datos de la arquitectura maestro-esclavo

Redis está inactivo, puede usar AOF o RDB para restaurar los datos, reproduciendo registros y

Redis está inactivo, ¿cómo lograr una alta disponibilidad?

Redis proporciona un modo maestro-esclavo, el nodo maestro y el nodo esclavo replica la copia de seguridad de datos en otros servidores de forma redundante

1. Descripción general de la replicación maestro-esclavo

efecto:

Reparación de fallas: cuando el nodo maestro está inactivo, otros nodos aún pueden brindar servicios;
Balanceo de carga: el nodo maestro brinda servicios de escritura y los nodos esclavos brindan servicios de lectura para compartir la presión;
Implementación de alta disponibilidad: la base para las implementaciones centinela y clúster

¿Cómo mantienen la coherencia el amo y el esclavo?

Redis proporciona la forma de biblioteca maestro-esclavo para mantener la consistencia de la copia de datos, y se adopta la forma de separación de lectura y escritura entre la biblioteca maestro-esclavo

Se adopta el método de separación de lectura y escritura :

Operación de lectura : se pueden ejecutar tanto bibliotecas maestras como esclavas;

Operación de escritura : la biblioteca principal se ejecuta primero y luego se sincroniza con la biblioteca de fuentes.

¿El propósito de la separación de lectura y escritura?

Para evitar que los servidores maestro y esclavo estén ejecutando la operación de escritura, cada modificación se envía a las instancias maestra y esclava, lo que provocará inconsistencia de datos en las réplicas de la instancia.

Puede imaginar que si en la figura anterior, tanto la biblioteca principal como la biblioteca esclava pueden recibir la operación de escritura del cliente, entonces un problema directo es: si el cliente modifica los mismos datos (como k1) tres veces, cada modificación la solicitud se envía a una instancia diferente, en

Si se ejecuta en diferentes instancias, las copias de estos datos en estas tres instancias son inconsistentes (v1, v2 y v3 respectivamente). Al leer estos datos, es posible leer el valor anterior.

Si desea que sus datos sean iguales, debe bloquearlos, y las instancias deben negociar si los modifican, y el bloqueo generará una sobrecarga adicional.

Solo la biblioteca maestra puede escribir, y se sincroniza con la biblioteca esclava sin negociación, y los datos permanecen consistentes.

2. Cree una arquitectura de servicio maestro-esclavo

3. Principio de replicación maestro-esclavo

La biblioteca maestra primero ejecuta la operación de escritura y luego se sincroniza con la biblioteca esclava para garantizar la coherencia de los datos.

3.1 Tres casos de sincronización

La primera copia completa de la biblioteca maestro-esclavo
Sincronización durante el funcionamiento normal de maestro y esclavo
La desconexión de red entre las bibliotecas maestra y esclava está sincronizada

3.1.1 La primera copia completa de la biblioteca maestro-esclavo

El primer proceso de copia se divide principalmente en tres etapas: la etapa de establecimiento de la conexión (es decir, la etapa de preparación), la biblioteca maestra sincroniza los datos con la etapa de la biblioteca esclava y envía el nuevo comando de escritura en la etapa de sincronización a la etapa de la biblioteca esclava.

Por ejemplo: ahora hay instancia 1 (ip: 172.16.19.3) e instancia 2 (ip: 172.16.19.5), ejecutamos el siguiente comando en la instancia 2 para convertir la instancia 2 en una biblioteca esclava de la instancia 1 y copiar datos:

réplica de 172.16.19.3 6379

establecer conexión

El primer escenario

La función principal de esta etapa es establecer una conexión entre los nodos maestro y esclavo para prepararse para la sincronización completa de datos. La biblioteca esclava establecerá una conexión con la biblioteca maestra, y la biblioteca esclava (ejecutar réplica de) envía el comando psync a la biblioteca maestra y le dice a la biblioteca maestra que la sincronización está por realizarse. Después de que la biblioteca maestra confirme la respuesta, el comienza la sincronización entre las bibliotecas maestra y esclava . ( La primera etapa es el proceso de establecer una conexión entre las bibliotecas maestra y esclava y negociar la sincronización, principalmente para prepararse para la replicación completa. En este paso, la biblioteca esclava y la biblioteca maestra establecen una conexión y le dicen a la biblioteca maestra que la sincronización está a punto de tener lugar, y la biblioteca maestra confirma la respuesta. Después de eso, la biblioteca maestra-esclava puede comenzar a sincronizarse ).

¿Cómo conoce la biblioteca esclava la información de la biblioteca principal y establece una conexión?

Después de configurar la IP y el puerto del nodo maestro en el elemento de configuración replicaof en el archivo de configuración del nodo esclavo, el nodo esclavo sabe que quiere conectarse al nodo maestro.

Se mantienen dos campos dentro del nodo esclavo, masterhost y masterport, que se utilizan para almacenar la información de IP y puerto del nodo maestro.

La biblioteca esclava (ejecuta replicaof) envía el comando psync a la biblioteca maestra, lo que indica que se realizará la sincronización de datos, y la biblioteca maestra inicia la replicación de acuerdo con los parámetros después de recibir el comando. El comando contiene dos parámetros , el ID de ejecución de la biblioteca maestra y el desplazamiento del progreso de la copia .

runID : cada inicio de instancia de Redis generará automáticamente una ID única. Para la primera replicación maestro-esclavo, aún no se conoce el runID de la base de datos maestra y el parámetro se establece en "?".
offset : La primera copia se establece en -1, lo que significa que es la primera copia, y se registra el desplazamiento del progreso de la copia.

Después de que la biblioteca principal reciba el comando psync, utilizará el comando de respuesta FULLRESYNC con dos parámetros: el ID de ejecución de la biblioteca principal y el desplazamiento del progreso de replicación actual de la biblioteca principal, y lo devolverá a la biblioteca esclava . Estos dos parámetros se registran cuando se recibe la respuesta de la biblioteca.

La respuesta FULLRESYNC indica la copia completa utilizada para la primera copia , es decir, la biblioteca maestra copiará todos los datos actuales a la biblioteca esclava. resincronizar

La biblioteca maestra sincroniza los datos con la biblioteca esclava

¿Por qué usar RDB no usar el archivo AOF?

Los archivos AOP son más grandes que los archivos RDB y la transmisión por red requiere mucho tiempo.

RDB funciona más rápido que el archivo AOF al inicializar datos de la biblioteca

Segunda etapa

La biblioteca maestra sincroniza todos los datos con la biblioteca esclava. Después de recibir los datos de la biblioteca, complete la carga de datos localmente. Esta etapa se basa en la RDB generada por la instantánea de memoria.

El maestro ejecuta el comando bgsave para generar un archivo RDB y envía el archivo a la biblioteca esclava. Al mismo tiempo, la biblioteca maestra crea un búfer de replicación para que cada esclavo registre todos los comandos de escritura recibidos desde la generación del archivo RDB. .

Después de recibir el archivo RDB de la biblioteca, guárdelo en el disco, borre los datos en la base de datos actual y luego cargue los datos del archivo RDB en la memoria. (Primero guarde el disco, borre los datos de la memoria y finalmente cargue rdb en la memoria)

Específicamente, la biblioteca maestra ejecuta el comando bgsave para generar un archivo RDB y luego envía el archivo a la biblioteca esclava. Después de recibir el archivo RDB de la biblioteca, la base de datos actual se borrará primero y luego se cargará el archivo RDB. Esto se debe a que la biblioteca esclava puede haber guardado otros datos antes de comenzar a sincronizarse con la biblioteca maestra a través del comando replicaof. Para evitar el impacto de los datos anteriores, la biblioteca esclava debe borrar primero la base de datos actual.

Durante el proceso de sincronización de datos de la biblioteca principal a la biblioteca esclava, la biblioteca principal no se bloqueará y aún podrá recibir solicitudes con normalidad. De lo contrario, el servicio de Redis se interrumpe. Sin embargo, las operaciones de escritura en estas solicitudes no se registran en el archivo RDB recién generado. Para garantizar la consistencia de los datos de la biblioteca maestro-esclavo, la biblioteca maestra utilizará un búfer de replicación especial en la memoria para registrar todas las operaciones de escritura recibidas después de generar el archivo RDB.

Enviar un nuevo comando de escritura a la biblioteca esclava

la tercera fase

Después de que el nodo esclavo carga la RDB, el nodo maestro envía los datos en el búfer de replicación al nodo esclavo, el esclavo los recibe y los ejecuta, y el nodo esclavo se sincroniza con el mismo estado que el nodo maestro.

Finalmente, en la tercera etapa, la biblioteca maestra enviará los comandos de escritura recién recibidos durante la ejecución de la segunda etapa a la biblioteca esclava. La operación específica es que cuando la biblioteca principal termine de enviar el archivo RDB, enviará las operaciones de modificación en el búfer de replicación a la biblioteca esclava, y la biblioteca esclava volverá a ejecutar estas operaciones. De esta forma se sincroniza la librería maestro-esclavo.

Recibir la solicitud con normalidad

La operación de escritura después de que se genera el archivo RDB no se registra en el archivo RDB en este momento. Para garantizar la consistencia de los datos de la base de datos maestro-esclavo, la biblioteca maestra utilizará un búfer de replicación en la memoria para registrar todas las operaciones de escritura después. se genera el archivo RDB.

¿Desea borrar la base de datos actual después de recibir el archivo RDB de la biblioteca?

Debido a que la biblioteca esclava puede guardar otros datos antes de comenzar a sincronizarse con la biblioteca maestra a través del comando replicaof, para evitar el impacto entre los datos maestros y esclavos.

¿Se explica el búfer de replicación?

Un búfer creado en el lado maestro, los datos almacenados son todas las operaciones de escritura de datos maestros en los siguientes tres períodos.

1) El maestro ejecuta bgsave para generar la operación de escritura durante la generación de RDB;

2) El maestro envía rdb a la operación de escritura durante la transmisión de la red esclava;

3) La operación de escritura durante la cual el archivo rdb de carga esclavo restaura los datos en la memoria.

Después de que cada cliente (comunicación de cliente, comunicación de biblioteca esclava) se conecte a Redis, Redis asignará un búfer de cliente dedicado y todas las interacciones de datos se llevarán a cabo a través de este búfer. (El maestro primero escribe los datos en este búfer y luego los envía a través de la red, completando así la interacción de datos). El búfer se utiliza especialmente para propagar el comando de escritura a la biblioteca esclava para garantizar la coherencia de los datos maestro-esclavo. Normalmente lo llamamos búfer de replicación.

Problemas causados por un búfer de replicación demasiado pequeño:

El búfer de replicación lo establece el esclavo de límite de búfer de salida del cliente. Cuando este valor es demasiado pequeño, la conexión de replicación maestro-esclavo se desconectará . (El búfer de replicación lo establece el esclavo de límite de búfer de salida del cliente. Cuando este valor es demasiado pequeño, la conexión de replicación maestro-esclavo se desconectará ).

Problemas causados por la desconexión de la conexión de replicación maestro-esclavo:

config set client-output-buffer-limit "esclavo 536870912 536870912 0"

1) Cuando se desconecta la conexión de replicación maestro-esclavo, el maestro liberará los datos relacionados con la conexión. Los datos en el búfer de replicación también se pierden y el proceso de replicación se reinicia entre el maestro y el esclavo.

2) Hay un problema más grave: la conexión de replicación maestro-esclavo está desconectada, lo que da como resultado un bucle infinito de operaciones de retransmisión bgsave y rdb reejecutadas en el maestro-esclavo.

Cuando el volumen de datos del nodo maestro es grande, o la demora de la red entre los nodos maestro y esclavo es grande, el tamaño del búfer puede exceder el límite y el nodo maestro se desconectará del nodo esclavo en este momento;

El problema causado por la gran cantidad de datos del nodo maestro: (la conexión maestro-esclavo está desconectada. Bucle infinito)

Esta situación puede causar una copia completa -> el desbordamiento del búfer de replicación provoca la interrupción de la conexión -> reconexión -> copia completa -> el desbordamiento del búfer del búfer de replicación provoca la interrupción de la conexión... ciclo.

¿Por qué la replicación de la biblioteca maestro-esclavo no usa AOF? En comparación con RDB, se pierden menos datos

Los archivos RDB son archivos binarios, y la eficiencia de E/S de la transmisión de red RDB y la escritura en el disco es mayor que la de AOF.
Al recuperar datos de la base de datos, la eficiencia de recuperación de RDB también es mayor que la de AOF.

3.1.2 El segundo tipo: replicación incremental (sincronización de desconexión de red)

¿Qué debo hacer si la red entre las bases de datos maestra y esclava está rota?

Antes de la versión 2.8, desconectar y volver a hacer una copia completa costaría mucho dinero. Después de 2.8, desconecte y vuelva a conectar, y el maestro-esclavo continuará sincronizándose de manera incremental.

Copia completa: sincronizar todos los datos

Replicación incremental: se utiliza para la replicación después de la interrupción de la red y otras situaciones. Solo los comandos de escritura ejecutados por el nodo maestro durante la interrupción se envían a los nodos esclavos, lo que es más eficiente que la replicación completa .

Cuando se desconecta la biblioteca maestra-esclava, la biblioteca maestra escribirá los comandos de operación de escritura recibidos durante el período de desconexión en el búfer de replicación y también escribirá estos comandos de operación.

También escriba en el búfer repl_backlog_buffer.

búfer utilizado de forma incremental

repl_backlog_buffer

Biblioteca principal: registre la ubicación que escribió

De la biblioteca: registra la posición que lees

El secreto de la replicación incremental desconectada y reconectada es el búfer repl_backlog_buffer. Siempre que el maestro registre la operación de instrucción de escritura en repl_backlog_buffer, debido a la memoria limitada, repl_backlog_buffer es una matriz circular de longitud fija. Si la matriz está llena, sobrescribirá el contenido anterior desde cero .

Al principio, las posiciones de escritura y lectura de la biblioteca maestra y la biblioteca esclava están juntas, que es su posición inicial. A medida que la biblioteca principal continúa recibiendo nuevas operaciones de escritura, su posición de escritura en el búfer se desviará gradualmente de la posición inicial. Usualmente usamos el desplazamiento para medir el tamaño de esta distancia de desplazamiento. Para la biblioteca principal, el desplazamiento correspondiente El desplazamiento es master_repl_offset. Cuantas más operaciones de escritura nuevas reciba la biblioteca principal, mayor será este valor.

De manera similar, después de que la biblioteca esclava termine de copiar el comando de operación de escritura, su posición de lectura en el búfer también comienza a cambiar gradualmente desde la posición inicial justo ahora.En este momento, el desplazamiento slave_repl_offset que se ha copiado de la biblioteca también está aumentando. En circunstancias normales, estas dos compensaciones son básicamente iguales.

El maestro usa master_repl_offset para registrar el desplazamiento de posición que ha escrito y el esclavo usa slave_repl_offset para registrar el desplazamiento que ha leído.

El maestro recibe la operación de escritura y se incrementa el desplazamiento. Después de que la biblioteca esclava continúa ejecutando instrucciones de escritura síncrona, el desplazamiento de repl_esclavo también aumenta.

En circunstancias normales, estas dos compensaciones son básicamente iguales. Durante la etapa de desconexión de la red, la biblioteca principal puede recibir nuevos comandos de operación de escritura, por lo que master_repl_offset será mayor que slave_repl_offset.

Cuando el maestro-esclavo se desconecta y se vuelve a conectar, el esclavo primero enviará el comando psync al maestro y, al mismo tiempo, enviará su propio runID, slave_repl_offset al maestro. La biblioteca principal juzgará la brecha entre su propio master_repl_offset y slave_repl_offset.

En este punto, el maestro solo necesita sincronizar los comandos entre master_repl_offset y slave_repl_offset con la biblioteca esclava.

Al igual que la parte central del diagrama esquemático, hay dos operaciones de poner de y poner df entre la biblioteca maestra y la biblioteca esclava Durante la replicación incremental, la biblioteca maestra solo necesita sincronizarlas con la biblioteca esclava.

Sin embargo, hay un punto que quiero enfatizar, porque repl_backlog_buffer es un búfer de anillo, por lo que después de que el búfer esté lleno, la biblioteca principal continuará escribiendo y, en este momento, se sobrescribirá la operación escrita previamente. Si la velocidad de lectura de la biblioteca esclava es relativamente lenta, puede hacer que las operaciones no leídas de la biblioteca esclava se sobrescriban con la nueva operación de escritura de la biblioteca maestra, lo que generará inconsistencias de datos entre las bibliotecas maestra y esclava.

Expansión Repl_backlog_buffer:

Si repl_backlog_buffer es demasiado pequeño, ¿qué debo hacer si la nueva operación de escritura del maestro lo sobrescribe antes de que se lea de la biblioteca?

Tenemos que encontrar una manera de evitar esta situación, y una vez que se sobrescriba, se realizará una copia completa. Podemos ajustar el parámetro repl_backlog_size para controlar el tamaño del búfer. Fórmula de cálculo:

repl_backlog_buffer = segundo * write_size_per_second

segundo : el tiempo promedio requerido para desconectarse del servidor y volver a conectarse al servidor maestro;
write_size_per_second : la cantidad promedio de datos de comando generados por el maestro por segundo (suma del comando de escritura y el tamaño de los datos);

Por ejemplo, si el servidor maestro escribe un promedio de 1 MB por segundo, y el esclavo tarda un promedio de 5 segundos en volver a conectarse al maestro después de una desconexión, entonces el tamaño del búfer de acumulación de replicación no puede ser inferior a 5 MB. .

Para estar seguro, el tamaño del búfer de acumulación de replicación se puede establecer en 2 * segundo * write_size_per_second, lo que garantiza que la mayoría de las desconexiones se puedan manejar con una resincronización parcial.

repl_backlog_buffer =2 * segundo * write_size_per_second

De esta forma, se reduce el riesgo de inconsistencia de datos entre las bases de datos maestra y esclava durante la replicación incremental. Sin embargo, si la cantidad de solicitudes simultáneas es muy grande, e incluso el doble del espacio del búfer no puede almacenar nuevas solicitudes de operación, en este momento, los datos de la base de datos maestro-esclavo aún pueden ser inconsistentes.

Para esta situación, por un lado, puede aumentar adecuadamente el valor de repl_backlog_size de acuerdo con los recursos de memoria del servidor donde se encuentra Redis, por ejemplo, configúrelo en 4 veces el tamaño del espacio de búfer; por otro lado, puede puede considerar el uso de un grupo de segmentos para compartir la carga de una sola biblioteca principal Pida presión.

¿Cómo determinar si realizar una sincronización completa o una sincronización parcial?

En Redis 2.8 y versiones posteriores, el nodo esclavo puede enviar el comando psync para solicitar la sincronización de datos. En este momento, según el estado actual de los nodos maestro y esclavo, el método de sincronización puede ser copia completa o copia parcial .

Juicio de copia completa o copia incremental:

La clave es la ejecución de psync:

El nodo esclavo envía el comando psync al maestro de acuerdo con el estado actual:

- Si el nodo esclavo nunca ejecutó replicaof, el nodo esclavo envía psync ? -1 para enviar una solicitud de copia completa al nodo maestro;
- Si el nodo esclavo ha ejecutado replicaof antes, enviará psync <runID> <offset>, donde runID es el runID del nodo maestro guardado por la última replicación, y offset es el desplazamiento de replicación guardado por el nodo esclavo cuando la última replicación terminó

El nodo maestro decide realizar una replicación total o parcial según el comando psync recibido y el estado actual del servidor:

- El runID es el mismo que el runID enviado por el nodo esclavo, y los datos posteriores a slave_repl_offset enviados por el nodo esclavo existen en el búfer repl_backlog_buffer, luego responde CONTINUAR, lo que indica que se realizará una copia parcial, y el nodo esclavo espera el nodo maestro para enviar los datos que faltan;
- El runID es diferente del runID enviado por el nodo esclavo, o los datos después de que slave_repl_offset enviados por el nodo esclavo ya no están en el búfer repl_backlog_buffer del nodo maestro (extruidos en la cola), luego responda al nodo esclavo FULLRESYNC <runid > <offset>, que indica Para realizar una replicación completa, runID representa el runID actual del nodo maestro, offset representa el desplazamiento actual del nodo maestro y el nodo esclavo guarda estos dos valores para uso futuro.

Si una biblioteca esclava se desconecta de la biblioteca principal durante demasiado tiempo, se sobrescribirán sus datos en la posición slave_repl_offset de la biblioteca principal repl_backlog_buffer En ese momento, se realizará una copia completa entre la biblioteca esclava y la biblioteca principal.

3.1.3 El tercer tipo: propagación de comandos basada en conexión larga

Cómo sincronizar el proceso de operación normal después de completar la sincronización completa

Propagación de comandos basada en conexiones largas: cuando la biblioteca maestra-esclava complete la replicación completa, se mantendrá una conexión de red entre ellos, y la biblioteca maestra volverá a sincronizar las operaciones de comando posteriores recibidas sucesivamente a la biblioteca esclava a través de esta conexión.

Propósito: El propósito de usar conexiones largas es evitar la sobrecarga causada por el establecimiento frecuente de conexiones.

En la fase de propagación de comandos, además de enviar comandos de escritura, los nodos maestro y esclavo también mantienen un mecanismo de latido: PING y REPLCONF ACK.

El modo en cascada maestro-esclavo comparte la presión de la biblioteca maestra durante la replicación completa

Al analizar el primer proceso de sincronización de datos entre las bases de datos maestra y esclava, puede ver que en una copia completa, para la base de datos maestra, se deben completar dos operaciones que consumen mucho tiempo: generar archivos RDB y transferir archivos RDB.

Si hay una gran cantidad de bibliotecas esclavas y deben replicarse completamente con la biblioteca principal, la biblioteca principal estará ocupada con el proceso secundario de bifurcación para generar archivos RDB y realizar una sincronización completa de datos. La operación de bifurcación impedirá que el subproceso principal procese las solicitudes normales, lo que ralentizará la respuesta de la biblioteca principal a las solicitudes de la aplicación. Además, la transferencia de archivos RDB también ocupará el ancho de banda de la red de la biblioteca principal, lo que también ejercerá presión sobre el uso de recursos de la biblioteca principal. Entonces, ¿existe una buena solución para compartir la presión sobre la biblioteca principal?

De hecho, existe, este es el modo "maestro-esclavo-esclavo".

En el modelo de biblioteca maestro-esclavo recién presentado, todas las bibliotecas esclavas están conectadas a la biblioteca maestra y toda la replicación completa también se realiza con la biblioteca maestra. Ahora, podemos usar el modo "maestro-esclavo-esclavo" para distribuir la presión de generar RDB y transmitir RDB desde la biblioteca maestra a la biblioteca esclava en forma de cascada.

En pocas palabras, cuando implementamos un clúster maestro-esclavo, podemos seleccionar manualmente una biblioteca esclava (por ejemplo, seleccionar una biblioteca esclava con una configuración de recursos de memoria más alta) para conectar en cascada otras bibliotecas esclavas . Luego, podemos seleccionar algunas bibliotecas esclavas (por ejemplo, un tercio de las bibliotecas esclavas) y ejecutar los siguientes comandos en estas bibliotecas esclavas, para que puedan establecer una relación maestro-esclavo con la biblioteca esclava recién seleccionada.

El puerto IP de la biblioteca esclava seleccionado por replicaof

De esta manera, estas bibliotecas esclavas sabrán que al sincronizar, ya no necesitan interactuar con la biblioteca principal, solo necesitan sincronizar las operaciones de escritura con las bibliotecas esclavas en cascada, lo que puede reducir la presión sobre la biblioteca principal, de la siguiente manera: se muestra en la imagen:

Mecanismo de latido: (verifique si la red está desconectada)

Maestro->Esclavo: PING

De vez en cuando, la biblioteca maestra enviará un comando ping a la biblioteca esclava con el fin de permitir que el nodo esclavo juzgue el tiempo de espera de la conexión.

Esclavo -> Maestro: REPLCONF ACK

En la fase de propagación de comandos , el servidor esclavo enviará comandos al servidor maestro una vez por segundo por defecto:

REPLCONF ACK <desplazamiento_replicación>

donde replication_offset es el desplazamiento de replicación actual del servidor. Enviar el comando REPLCONF ACK tiene tres funciones para los servidores maestro y esclavo: replconf ack

Detecta el estado de conexión de red de los servidores maestro y esclavo.
Implementación auxiliar de la opción min-slaves.
Para detectar la pérdida del comando, el nodo esclavo envía su propio slave_replication_offset, y el nodo maestro lo comparará con su propio master_replication_offset.Si faltan los datos del nodo esclavo, el nodo maestro encontrará y empujará los datos faltantes del búfer repl_backlog_buffer . Tenga en cuenta que los búferes offset y repl_backlog_buffer se pueden usar no solo para la replicación parcial, sino también para tratar situaciones como la pérdida de comando; la diferencia es que el primero se realiza después de la desconexión y la reconexión, mientras que el último es cuando los nodos maestro y esclavo están no desconectado realizado a continuación.

3.1.3 Resumen

resumen

Después de aprender el principio básico de la sincronización de la biblioteca maestro-esclavo de Redis, en resumen, hay tres modos: copia completa, propagación de comandos basada en una conexión larga y copia incremental.

Aunque la replicación completa requiere mucho tiempo, la replicación completa es inevitable para la biblioteca esclava si es la primera sincronización. Por lo tanto, le daré una pequeña sugerencia: la base de datos de una instancia de Redis no debe ser demasiado grande y el tamaño de una la instancia debe ser varias. El nivel de GB es más apropiado, lo que puede reducir la sobrecarga de generación, transmisión y recarga de archivos RDB. Además, para evitar múltiples replicaciones completas simultáneas de la biblioteca maestra y una presión de sincronización excesiva en la biblioteca maestra, también podemos usar el modo en cascada "maestro-esclavo-esclavo" para aliviar la presión sobre la biblioteca maestra.

La replicación de conexiones largas es una etapa de sincronización regular después de que la base de datos maestro-esclavo se ejecuta normalmente. En esta etapa, la sincronización entre las bibliotecas maestra y esclava se logra mediante la propagación de comandos. Sin embargo, si hay una desconexión de la red durante este período, la replicación incremental será útil. En particular, te recomiendo que prestes atención al parámetro de configuración repl_backlog_size. Si se configura demasiado pequeño, durante la fase de replicación incremental, es posible que el progreso de la replicación de la biblioteca esclava no alcance el nivel de la biblioteca maestra, lo que hará que la biblioteca esclava vuelva a realizar la replicación completa. Por lo tanto, al aumentar este parámetro, se puede reducir el riesgo de realizar una copia completa de la biblioteca cuando la red está desconectada.

Sin embargo, aunque el modo de biblioteca maestro-esclavo usa la separación de lectura y escritura para evitar la inconsistencia de los datos causada por la escritura de varias instancias al mismo tiempo, aún enfrenta el riesgo potencial de falla de la biblioteca maestra.

Resumen básico

Cada biblioteca esclava registrará su propio slave_repl_offset, y el progreso de replicación de cada biblioteca esclava no es necesariamente el mismo. (La biblioteca esclava registrará el desplazamiento recibido y el progreso de la copia de cada biblioteca esclava puede ser inconsistente)

Al volver a conectarse con la biblioteca principal para la recuperación, la biblioteca esclava enviará el Slave_repl_offset registrado por sí mismo a la biblioteca principal a través del comando psync, y la biblioteca principal determinará si la biblioteca esclava puede realizar una replicación incremental o una copia completa de acuerdo con la replicación respectiva. progreso de la copia de la biblioteca esclava. (De acuerdo con los datos del conjunto de ofertas de runid y offset enviados por psync para determinar si se debe realizar una copia completa)

búfer de replicación 和 repl_backlog_buffer

El búfer de replicación corresponde a cada esclavo y lo establece config set client-output-buffer-limit slave.
repl_backlog_buffer es un búfer de anillo, solo habrá uno en todo el proceso maestro y todos los esclavos son comunes. El tamaño de repl_backlog se establece mediante el parámetro repl-backlog-size, el tamaño predeterminado es 1M y su tamaño puede basarse en el comando generado por segundo (el maestro ejecuta rdb bgsave) + (el maestro envía rdb al esclavo) + ( esclavo cargar archivo rdb) tiempo y para estimar el tamaño del búfer de trabajo pendiente, el valor de repl-backlog-size no es menor que el producto de estos dos.

En general, el búfer de replicación es el búfer que se usa en la biblioteca maestra para los clientes conectados a la biblioteca esclava cuando la biblioteca maestra-esclava realiza una replicación completa, mientras que repl_backlog_buffer se usa para admitir la replicación incremental desde la biblioteca y se usa para save escribe en la biblioteca maestra Un búfer dedicado para la operación.

Cuando la biblioteca maestra-esclava de Redis se está replicando, cuando la biblioteca maestra quiere enviar el comando de operación de escritura durante el período de copia completa a la biblioteca esclava, la biblioteca maestra primero creará un cliente (búfer de replicación) para conectarse a la biblioteca esclava, y luego pase este cliente y envíe el comando de operación de escritura a la biblioteca esclava. En la memoria, el cliente de la biblioteca principal corresponderá a un búfer, que se denomina búfer de replicación. Redis controla el tamaño de este búfer a través del elemento de configuración client_buffer. La biblioteca maestra creará un cliente para cada biblioteca esclava, por lo que el búfer de replicación no se comparte, pero cada biblioteca esclava tiene un cliente correspondiente.

repl_backlog_buffer es un búfer dedicado.Después de que se inicia el servidor Redis, comienza a recibir comandos de operación de escritura todo el tiempo, que es compartido por todas las bibliotecas esclavas. La biblioteca maestra y la biblioteca esclava registrarán cada una su propio progreso de replicación, por lo que cuando diferentes bibliotecas esclavas se están recuperando, enviarán su propio progreso de replicación (slave_repl_offset) a la biblioteca maestra, y la biblioteca maestra puede sincronizarse con ella de forma independiente.

5. Problema de aplicación maestro-esclavo

Bajo la replicación maestro-esclavo, ¿eliminará el nodo esclavo los datos caducados?

Para la consistencia de los datos de los nodos maestro y esclavo, los nodos esclavos no eliminarán datos activamente

5.1 Redis tiene dos estrategias de eliminación:

Eliminación diferida: cuando el cliente consulta los datos correspondientes, Redis juzga si los datos han caducado y los elimina si caducan.
Eliminación periódica: Redis elimina los datos caducados a través de tareas programadas.

¿El cliente leerá los datos vencidos al leer los datos del nodo?

A partir de Redis 3.2, al leer datos de un nodo, primero determine si los datos han caducado. Si caduca, no volverá al cliente y eliminará los datos.

5.2 Límite de tamaño de memoria independiente

Si la memoria autónoma de Redis alcanza los 10 GB, el tiempo de sincronización de un nodo esclavo está al nivel de varios minutos; si hay más nodos esclavos, la velocidad de recuperación será más lenta. Si la carga de lectura del sistema es alta y los nodos esclavos no pueden proporcionar servicios durante este período, ejercerá mucha presión sobre el sistema.

Si la cantidad de datos es demasiado grande, el nodo maestro tarda demasiado en bifurcar + guardar el archivo RDB durante la fase de copia completa, y el nodo esclavo no puede recibir datos durante mucho tiempo para activar un tiempo de espera. los nodos maestro y esclavo también pueden caer en la copia completa -> el tiempo de espera provoca la interrupción de la replicación- >Reconectar->Copia completa->El tiempo de espera hace que la copia se interrumpa ... ciclo.

Además, además de la cantidad absoluta de la memoria de una sola máquina del nodo maestro, no debe ser demasiado grande, y su proporción de la memoria del host no debe ser demasiado grande: es mejor usar solo 50% - 65% de la memoria, dejando 30% - 45% de la memoria para comandos bgsave y crear buffers de copia, etc.

6. Resumen

El papel de la replicación maestro-esclavo: los archivos binarios AOF y RDB garantizan una recuperación rápida de los datos durante el tiempo de inactividad y evitan la pérdida de datos tanto como sea posible. Sin embargo, los servicios no se pueden proporcionar después de un tiempo de inactividad, por lo que se ha desarrollado una arquitectura maestro-esclavo y una separación de lectura y escritura.
El principio de replicación maestro-esclavo: fase de establecimiento de conexión, fase de sincronización de datos y fase de propagación de comandos; la fase de sincronización de datos se divide en replicación completa y replicación parcial; en la fase de propagación de comandos, hay comandos PING y REPLCONF ACK entre el maestro y nodos esclavos para realizar la detección mutua de latidos.
Aunque la replicación maestro-esclavo resuelve o alivia problemas como la redundancia de datos, la recuperación de fallas y el equilibrio de carga de lectura, sus defectos aún son obvios: la recuperación de fallas no se puede automatizar, las operaciones de escritura no se pueden equilibrar, la capacidad de almacenamiento está limitada por una sola máquina; la solución a estos problemas, necesita la ayuda de centinela y clúster, lo presentaré en un artículo posterior, bienvenido a prestar atención.

2. Problemas encontrados en la conmutación por error y la sincronización maestro-esclavo de Redis

El mecanismo de sincronización maestro-esclavo de Redis no solo permite que la biblioteca esclava atienda más solicitudes de lectura y comparta la presión de la biblioteca principal, sino que también realiza el cambio de biblioteca maestro-esclavo para brindar servicios altamente confiables cuando falla la biblioteca principal.

Cuando se usa realmente el mecanismo maestro-esclavo, se encontrarán tres problemas: los datos maestro-esclavo son inconsistentes, se leen datos caducados y el elemento de configuración se configura de manera irrazonable, lo que lleva a que el servicio se cuelgue.

1. Datos maestro-esclavo inconsistentes

La inconsistencia de datos maestro-esclavo significa que el valor leído por el cliente de la biblioteca esclava es inconsistente con el valor más reciente en la biblioteca maestra.

1.1 Ejemplo

Suponga que el valor de edad del usuario previamente guardado por la biblioteca maestra-esclava es 19, pero la biblioteca maestra recibió un comando de modificación y actualizó estos datos a 20, pero el valor en la biblioteca esclava sigue siendo 19. Luego, si el cliente lee el valor de edad del usuario del repositorio, leerá el valor anterior.

1.2 Razones principales:

La replicación de comandos entre las bibliotecas maestra y esclava se realiza de forma asíncrona .

Específicamente, en la fase de propagación del comando de la biblioteca maestra-esclava, después de que la biblioteca maestra reciba un nuevo comando de escritura, lo enviará a la biblioteca esclava. Sin embargo, la biblioteca principal no espera hasta que la biblioteca esclava realmente ejecuta el comando y luego devuelve el resultado al cliente, pero la biblioteca principal en sí misma devuelve el resultado al cliente después de ejecutar el comando localmente. Si la biblioteca esclava no ha ejecutado el comando sincronizado desde la biblioteca maestra, los datos entre las bibliotecas maestra y esclava serán inconsistentes.

1.3 La razón por la que la biblioteca esclava se retrasará en la ejecución de los comandos de sincronización

Motivo 1: Retraso en la transmisión de la red

La red entre las bibliotecas maestra y esclava puede tener retrasos en la transmisión, por lo que la biblioteca esclava no puede recibir los comandos enviados por la biblioteca maestra a tiempo, y el tiempo de ejecución del comando de sincronización en la biblioteca esclava se retrasará.

Razón 2: Bloqueado

Incluso si la biblioteca esclava recibe el comando de la biblioteca maestra a tiempo, puede bloquearse porque está procesando otros comandos de alta complejidad (como los comandos de operación de configuración). La biblioteca esclava debe terminar de procesar el comando actual antes de ejecutar la operación de comando enviada por la biblioteca maestra, lo que provocará la inconsistencia de datos maestro-esclavo. Durante el período en que se retrasa el comando de la biblioteca principal, la propia biblioteca principal puede realizar nuevas operaciones de escritura. De esta manera, el grado de inconsistencia de datos entre la base de datos maestra y esclava se verá agravado aún más.

1.4 Soluciones

Método 1: hacer que la red de configuración sea buena

En términos de configuración del entorno de hardware, debemos hacer todo lo posible para garantizar que la conexión de red entre las bibliotecas maestra y esclava esté en buenas condiciones . Por ejemplo, debemos evitar implementar bibliotecas maestro-esclavo en diferentes salas de computadoras, o evitar implementar aplicaciones de uso intensivo de la red (como aplicaciones de análisis de datos) y bibliotecas maestro-esclavo de Redis juntas.

Método 2: Programa externo ayuda a intervenir

Desarrolle un programa externo para monitorear el progreso de la replicación entre bibliotecas maestras y esclavas

Debido a que el comando de replicación INFO de Redis puede ver la información de progreso de la biblioteca maestra que recibe el comando de escritura (master_repl_offset) y la información de progreso de la biblioteca esclava que copia el comando de escritura (slave_repl_offset), puede desarrollar un programa de monitoreo, primero use el INFO Comando de replicación para verificar la biblioteca maestra y esclava Progreso, reste slave_repl_offset de master_repl_offset para obtener la diferencia en el progreso de replicación entre la biblioteca esclava y la biblioteca maestra.

Si la diferencia de progreso de una biblioteca esclava es mayor que el umbral preestablecido, el cliente ya no se conectará a la biblioteca esclava para leer datos, lo que reduce la situación de lectura de datos inconsistentes. Para evitar la situación de que el cliente y todas las bibliotecas esclavas no puedan conectarse, es necesario establecer un umbral mayor para la diferencia de progreso de replicación.

Este proceso se puede ejecutar periódicamente para monitorear las inconsistencias entre las bibliotecas maestra y esclava

El programa de monitoreo siempre puede monitorear el progreso de la copia de la biblioteca esclava, y cuando el progreso de la copia de la biblioteca esclava se pone al día con la biblioteca principal, el cliente puede conectarse nuevamente a estas bibliotecas esclavas.

2. Leer datos caducados

Cuando se usa un clúster maestro-esclavo de Redis, a veces se leen datos obsoletos. Por ejemplo, el tiempo de vencimiento de los datos X es 202010240900, pero el cliente aún puede leer los datos X de la biblioteca en 202010240910

2.1 La razón por la que el cliente puede leer datos caducados

Esto se debe a la estrategia de eliminación de datos caducados de Redis. Redis utiliza dos estrategias para eliminar datos caducados al mismo tiempo, a saber, la estrategia de eliminación diferida y la estrategia de eliminación normal.

Estrategia de eliminación diferida: no se elimina inmediatamente después del vencimiento, se elimina cuando hay una solicitud para leer nuevamente

Cuando se accede a una clave caducada, Redis comprueba si la clave está caducada. Si caduca, se eliminará inmediatamente. Si no ha caducado, Redis seguirá procesándola como una clave normal. Este enfoque se denomina eliminación diferida, porque Redis solo verifica la caducidad cuando se necesita acceder a una clave y la elimina cuando encuentra que ha caducado.

La ventaja de esta estrategia es minimizar el uso de los recursos de la CPU mediante operaciones de eliminación y no perder más tiempo revisando y eliminando datos no utilizados. Sin embargo, esta estrategia hará que una gran cantidad de datos caducados permanezcan en la memoria, ocupando más recursos de memoria. Redis usa esta estrategia al mismo tiempo que usa la segunda estrategia: la estrategia de eliminación regular.

Estrategia de eliminación periódica: elimine todos los valores clave caducados durante un período de tiempo

Redis también utiliza una estrategia de eliminación periódica para eliminar claves caducadas. Bajo esta estrategia, Redis escaneará la base de datos de vez en cuando, encontrará todas las claves caducadas y las eliminará. Este método se denomina eliminación periódica, porque Redis realizará esta operación periódicamente.

ilustrar

La estrategia de eliminación diferida permite que Redis use la memoria de manera más eficiente porque solo verifica la caducidad cuando se necesita acceder a una clave. Sin embargo, puede hacer que las claves caducadas permanezcan en la memoria durante mucho tiempo hasta la próxima vez que se acceda a ellas. La estrategia de eliminación periódica puede garantizar que las claves caducadas se eliminen a tiempo, pero puede tener un cierto impacto en el rendimiento, ya que necesita recorrer periódicamente toda la base de datos. Para equilibrar el uso de la memoria y el rendimiento, Redis suele utilizar ambas estrategias al mismo tiempo.

La estrategia de eliminación regular puede liberar algo de memoria. Para evitar el impacto de demasiadas operaciones de eliminación en el rendimiento, Redis verifica aleatoriamente la cantidad de datos cada vez que no es grande. Si hay muchos datos caducados y no se ha accedido a ellos, los datos permanecerán en la instancia de Redis. La razón por la que las aplicaciones comerciales leen datos caducados es que estos datos retenidos son un factor importante.

Después de implementar la estrategia de eliminación diferida, los datos no se eliminarán realmente hasta que se acceda nuevamente. Si el cliente lee los datos caducados retenidos de la biblioteca principal, la biblioteca principal activará la operación de eliminación y, en ese momento, el cliente no leerá los datos caducados. Sin embargo, la biblioteca esclava en sí misma no realizará la operación de eliminación. Si el cliente accede a los datos caducados retenidos en la biblioteca esclava, la biblioteca esclava no activará la eliminación de datos.

¿La biblioteca esclava devolverá los datos caducados al cliente?

Antes de la versión 3.2 de Redis, la biblioteca esclava devolvía datos caducados. Después de Redis3.2, la biblioteca esclava no devolverá datos caducados, pero devolverá un valor nulo, pero aún es posible leerlo.

Si está utilizando una versión anterior a Redis 3.2, cuando la biblioteca esclava atienda una solicitud de lectura, no juzgará si los datos han caducado, sino que devolverá los datos caducados.
Después de la versión 3.2, Redis ha realizado mejoras: si los datos leídos han caducado, aunque la biblioteca esclava no los elimine, devolverá un valor nulo, lo que impide que el cliente lea los datos caducados. Por lo tanto, cuando aplique clústeres maestro-esclavo, intente usar Redis 3.2 y superior.

Si usa una versión posterior a Redis 3.2, aún leerá los datos vencidos. Esto está relacionado con el comando que usa Redis para establecer el tiempo de vencimiento. El tiempo de vencimiento establecido por algunos comandos para los datos puede retrasarse en la biblioteca esclava, lo que resulta en datos que deberían caducar Los datos se leen de la biblioteca de nuevo

Descripción del comando para establecer el tiempo de caducidad de los datos

EXPIRE y PEXPIRE: Establecen el tiempo de supervivencia de los datos desde que se ejecuta el comando;
EXPIREAT y PEXPIREAT: establecerán directamente el tiempo de caducidad de los datos en un punto específico en el tiempo.

ejemplo

El primer ejemplo es usar el comando EXPIRE. Cuando se ejecuta el siguiente comando, el tiempo de vencimiento de la clave de prueba se establece en 60 segundos más tarde.

caducar clave de prueba 60

El segundo ejemplo es usar el comando EXPIREAT. Por ejemplo, para dejar que testkey expire a las 9 a. m. del 24 de octubre de 2020, el 1603501200 en el comando es la marca de tiempo del 24 de octubre a las 9 a. m. en segundos.

expireat testkey 1603501200

Cómo el comando da como resultado la lectura de datos obsoletos

La biblioteca maestra-esclava está completamente sincronizada. Después de recibir el comando EXPIRE, la biblioteca maestra lo ejecuta directamente. Una vez completada la sincronización completa, se envía a la biblioteca esclava. Cuando la biblioteca esclava se ejecuta, el tiempo de supervivencia se agregará a la hora actual, y el tiempo de caducidad se retrasará significativamente.

ejemplo

Supongamos que la hora actual es a las 9 a. m. del 24 de octubre de 2020, la biblioteca maestra-esclava se está sincronizando y la biblioteca principal ha recibido un comando: EXPIRE testkey 60, lo que significa que la hora de vencimiento de la clave de prueba es a las 9:1 a. 24, y la biblioteca principal Este comando se ejecutó directamente.

Sin embargo, la sincronización completa de la biblioteca maestro-esclavo tardó 2 minutos en completarse. Cuando la biblioteca esclava comenzó a ejecutar este comando, el tiempo ya era 9:2. El comando EXPIRE es para establecer el tiempo de caducidad de la clave de prueba en 60 s después de la hora actual, que es 9:3. Si el cliente lee testkey de la biblioteca a las 9:02:30, todavía puede leer el valor de testkey. Sin embargo, la clave de prueba ha expirado

Para evitar esta situación, utilice el comando EXPIREAT/PEXPIREAT en las aplicaciones empresariales para establecer el tiempo de caducidad de los datos en un punto de tiempo específico para evitar la lectura de datos caducados.

3. Resumen parcial

Los datos maestro y esclavo son inconsistentes. Redis utiliza la replicación asincrónica, por lo que no puede lograr una garantía de consistencia fuerte (los datos maestro-esclavo son consistentes en todo momento), y la inconsistencia de los datos es inevitable. Lo que debe hacerse: garantizar un buen entorno de red, usar el programa para monitorear el progreso de la copia de la biblioteca esclava, una vez que el progreso de la copia de la biblioteca esclava exceda el umbral, no permita que el cliente se conecte a la biblioteca esclava

La lectura de datos vencidos se puede evitar de antemano. Un método es usar Redis 3.2 y superior; puede usar el comando EXPIREAT/PEXPIREAT para establecer el tiempo de vencimiento para evitar el retraso del tiempo de vencimiento de los datos en la biblioteca esclava. Cabe señalar que debido a que EXPIREAT/PEXPIREAT establece el punto de tiempo, los relojes en los nodos maestro y esclavo deben ser consistentes.El método específico es sincronizar los relojes de los nodos maestro y esclavo con el mismo servidor NTP (servidor de tiempo)

4. El servicio se cuelga debido a elementos de configuración irrazonables

Hay dos elementos de configuración involucrados: modo protegido y tiempo de espera de nodo de clúster.

1.elemento de configuración de modo protegido

El propósito de este elemento de configuración es limitar si otros servidores pueden acceder a la instancia de Sentinel. Cuando la configuración se establece en sí, solo el servidor local puede acceder a la instancia de Sentinel (la implementación de esta instancia se considera local). Cuando se establece en no, otros servidores también pueden acceder a la instancia de Sentinel.

Si el modo protegido se establece en sí y las instancias restantes de Sentinel se implementan en otros servidores, no habrá comunicación entre estas instancias de Sentinel. La biblioteca principal falla, Sentinel no puede determinar si la biblioteca principal está fuera de línea y no puede realizar el cambio maestro-esclavo y, finalmente, el servicio Redis no está disponible.

Al aplicar un clúster maestro-esclavo, preste atención a establecer el elemento de configuración de modo protegido en no y establecer el elemento de configuración de vinculación a la dirección IP de otra instancia de Sentinel. Solo el centinela con la dirección IP configurada en enlace puede acceder a la instancia actual, lo que no solo garantiza la comunicación entre instancias para el cambio maestro-esclavo, sino que también garantiza la seguridad del centinela.

ejemplo:

Si se establecen los siguientes elementos de configuración, las instancias de Sentinel implementadas en los tres servidores 192.168.10.3/4/5 pueden comunicarse entre sí y realizar la conmutación maestro-esclavo.

modo protegido no
enlazar 192.168.10.3 192.168.10.4 192.168.10.5

elemento de configuración 2.cluster-node-timeout

Este elemento de configuración establece el período de tiempo de espera para que las instancias en Redis Cluster respondan a los mensajes de latido.

Cuando el modo "un maestro y un esclavo" está configurado para cada instancia en el clúster de Redis Cluster, si la instancia maestra falla, la instancia esclava cambiará a la instancia maestra. Debido al impacto del retraso de la red y la ejecución de la operación de conmutación, el el tiempo de conmutación puede ser más largo, lo que provocará que el latido de la instancia se agote (excediendo el tiempo de espera del nodo del clúster). Después de que se agote el tiempo de espera de la instancia, Redis Cluster la considerará anormal . La condición para el funcionamiento normal de Redis Cluster es que más de la mitad de las instancias puedan operar con normalidad.

Si más de la mitad de las instancias realizan un cambio maestro-esclavo, y el tiempo de cambio maestro-esclavo es demasiado largo, el latido de más de la mitad de las instancias puede agotarse, lo que puede provocar que todo el clúster se cuelgue. Se recomienda aumentar el tiempo de espera del nodo del clúster (por ejemplo, de 10 a 20 segundos).

5. Resumen

Pueden ocurrir tres posibles problemas cuando se sincroniza la biblioteca maestro-esclavo: los datos maestro-esclavo son inconsistentes, los datos vencidos se leen y el elemento de configuración irrazonable hace que el servicio se cuelgue

Acerca de la inconsistencia de los datos de la base de datos maestro-esclavo

El elemento de configuración slave-serve-stale-data en Redis establece si la biblioteca esclava puede manejar comandos de lectura y escritura de datos, configúrelo en no, la biblioteca esclava solo puede entregar comandos INFO, SLAVEOF y evitar la lectura de datos inconsistentes de la biblioteca.

La diferencia entre el elemento de configuración lave-serve-stale-data y el esclavo de solo lectura

Slave-read-only es para establecer si la biblioteca esclava puede procesar comandos de escritura. Cuando Slave-read-only se establece en sí, la biblioteca esclava solo puede procesar solicitudes de lectura y no puede procesar solicitudes de escritura.

¿Es una buena manera de configurar el esclavo de solo lectura en no, para que los datos se puedan eliminar directamente de la biblioteca, para evitar leer datos caducados?

Respuesta: Las operaciones de adición, eliminación y modificación en la replicación maestro-esclavo deben realizarse en la biblioteca maestra. Incluso si la biblioteca esclava se puede eliminar, no la elimine de la biblioteca esclava, de lo contrario, se producirán inconsistencias en los datos. Los relojes de la biblioteca maestro-esclavo no están sincronizados, lo que da como resultado un tiempo de eliminación inconsistente de la biblioteca maestro-esclavo. caducar se retrasa

Para la clave que ya ha establecido el tiempo de caducidad, la biblioteca principal utiliza el comando expire para restablecer el tiempo de caducidad cuando la clave está a punto de caducar. Por ejemplo, una clave se establece originalmente para caducar después de 10 s. El comando expire establece la caducidad tiempo de la llave a 60s más tarde. Sin embargo, cuando el comando de caducidad se transmite desde la biblioteca maestra a la biblioteca esclava, debido a retrasos en la red, la biblioteca esclava no recibió el comando de caducidad a tiempo (por ejemplo, la biblioteca esclava recibió el comando de caducidad después de un retraso de 3 s). por lo que la biblioteca esclava sigue el tiempo de caducidad original. La clave caducada se elimina, lo que conduce a la inconsistencia de los datos maestro-esclavo. (Después de la sincronización maestro-esclavo, la biblioteca esclava ejecutará el comando expire)

Un artículo para informarle sobre la sincronización de Redis: explique todo en detalle