Algunas cosas sobre Redis | Alta concurrencia y alta disponibilidad

Si usa la tecnología de almacenamiento en caché de redis, debe considerar cómo usar redis para agregar varias máquinas para asegurarse de que redis sea altamente concurrente y cómo hacer que Redis se asegure de que no muera inmediatamente después de que falle.

Alta simultaneidad de Redis: arquitectura maestro-esclavo, un maestro y varios esclavos. En términos generales, muchos proyectos son suficientes. Se usa un solo maestro para escribir datos y una sola máquina tiene decenas de miles de QPS. Se usan muchos esclavos para realizar consultas 100.000 QPS por segundo.

Si bien redis tiene una alta simultaneidad, también debe admitir una gran cantidad de datos: un maestro y varios esclavos, cada instancia contiene datos completos. Por ejemplo, redis maestro tiene 10 G de memoria. De hecho, solo puede acomodar 10 g de datos. Si su caché tiene una gran cantidad de datos, alcanzando docenas de g, o incluso cientos de go algunas t, entonces necesita un clúster de redis y, después de usar un clúster de redis, puede proporcionar cientos de miles de datos por segundo Leer y escribir al mismo tiempo.

Alta disponibilidad de Redis: si implementa una arquitectura maestro-esclavo, puede agregar un centinela, lo cual se puede lograr. Cualquier tiempo de inactividad de la instancia cambiará automáticamente entre maestro y esclavo.

Los detalles se describen a continuación.

1. ¿Cómo lleva Redis solicitudes de lectura de más de 100.000 a través de la separación de lectura y escritura?

1. La relación entre la alta concurrencia de redis y la alta concurrencia de todo el sistema

Si Rredis quiere participar en una alta concurrencia, necesita hacer un buen trabajo en la caché subyacente, de modo que menos solicitudes vayan directamente a la base de datos, porque la alta concurrencia de la base de datos es más problemática de implementar y algunas operaciones tienen requisitos de transacción. , etc., por lo que es muy difícil lograr una concurrencia muy alta.

La concurrencia de Redis no es suficiente para la concurrencia de todo el sistema, pero redis, como toda la arquitectura de caché a gran escala, es una parte muy importante de la arquitectura que admite alta concurrencia.

Para lograr una alta concurrencia en el sistema, el middleware de caché y el sistema de caché primero deben poder admitir una alta concurrencia y, luego, después de un buen diseño general de la arquitectura de caché (caché multinivel, caché de hotspot), ¿puede realmente admitir alta concurrencia?

2. Redis no puede soportar el cuello de botella de alta concurrencia

El cuello de botella de que Redis no puede soportar una alta concurrencia es principalmente un problema de una sola máquina, es decir, solo hay una redis, no importa cuán bueno sea el rendimiento de la máquina, hay un límite superior.

3. Cómo admitir una mayor simultaneidad

Redis independiente no puede admitir una concurrencia demasiado alta. Si desea admitir una mayor concurrencia, la lectura y la escritura se pueden separar. Para la caché, generalmente admite una alta concurrencia de lectura y la solicitud de escritura es relativamente pequeña, por lo que se puede leer y escribir en función de la arquitectura maestro-esclavo.

Configure una máquina maestra (maestra) para escribir datos, configure varios esclavos (esclavo) para leer datos y sincronice los datos con el esclavo después de que el maestro reciba los datos, de modo que el esclavo pueda configurar varias máquinas. Puede aumentar la concurrencia general .

2. La importancia para la seguridad de la replicación de redis y la persistencia del maestro en la arquitectura maestro-esclavo

1. Principio de replicación de Redis

Varios nodos esclavos se cuelgan debajo de un nodo maestro, y la operación de escritura escribe los datos en el nodo maestro. Luego, después de que el maestro escribe, los datos se sincronizan con todos los nodos esclavos a través de operaciones asincrónicas para garantizar que los datos de todos los nodos sean Consistente.

2. El mecanismo central de la replicación de Redis

(1) Redis replica los datos en el nodo esclavo de manera asincrónica, pero a partir de redis 2.8, el nodo esclavo confirmará periódicamente la cantidad de copias que replica cada vez.

(2) Un nodo maestro puede configurar varios nodos salve.

(3) El nodo esclavo también puede conectarse a otros nodos esclavos.

(4) Cuando el nodo esclavo realiza la replicación, no bloqueará el trabajo normal del nodo maestro.

(5) Cuando el nodo esclavo está realizando la replicación, no bloqueará sus propias operaciones. Utilizará los datos antiguos para proporcionar servicios; pero cuando la replicación esté completa, deberá eliminar los datos antiguos y cargar los datos nuevos. Suspensión de servicio.

(6) El nodo esclavo se utiliza principalmente para la expansión horizontal y la separación de lectura y escritura. El nodo esclavo expandido puede mejorar el rendimiento.

3. Importancia para la seguridad de la persistencia del maestro en la arquitectura maestro-esclavo

Si se adopta esta arquitectura maestro-esclavo, entonces se debe activar la persistencia del nodo maestro. No se recomienda utilizar el nodo esclavo como una copia de seguridad en caliente del nodo maestro, porque si este es el caso, si el maestro se cae, los datos del maestro se perderán. Después del reinicio, los datos estarán vacíos Si otros nodos esclavos vienen a replicar datos, se copiarán a vacío, por lo que se perderán los datos de todos los nodos.

Es necesario realizar una variedad de copias de seguridad en frío de los archivos de copia de seguridad para evitar que toda la máquina se averíe y se pierdan los datos rdb de la copia de seguridad.

El interesante contenido del desarrollo de servidores Linux C / C ++ incluye: C / C ++, Linux, Nginx, ZeroMQ, MySQL, Redis, MongoDB, ZK, transmisión de medios, P2P, kernel de Linux, Docker, TCP / IP, corrutina, DPDK y más Intercambio de conocimientos avanzados, adquisición de vídeo + qun: Salto

3. Principio de replicación maestro-esclavo de Redis, transferencia reanudable, replicación sin disco, procesamiento de claves vencidas

1. Principio de replicación maestro-esclavo

① Al iniciar un nodo esclavo, enviará un comando PSYNC al nodo maestro.

②Si el nodo esclavo se va a reconectar al nodo maestro, entonces el nodo maestro solo copiará los datos faltantes al esclavo; si es la primera vez que se conecta al nodo maestro, se activará una resincronización completa.

③Al iniciar la resincronización completa, el maestro iniciará un subproceso en segundo plano para generar un archivo de instantánea RDB y también almacenará en la memoria todos los comandos de escritura recién recibidos del cliente.

④ El nodo maestro envía el archivo RDB generado al nodo esclavo, y el esclavo ahora lo escribe en el disco local y luego lo carga desde el disco a la memoria. Luego, el nodo maestro enviará el comando de escritura almacenado en caché en la memoria al nodo esclavo, y el nodo esclavo también sincronizará esta parte de los datos.

⑤ Si el nodo esclavo se desconecta del nodo maestro debido a una falla en la red, se volverá a conectar automáticamente.

⑥ Si el maestro descubre que hay varios nodos esclavos para reconectar, solo iniciará una operación de guardado rdb para servir a todos los nodos esclavos con una copia de los datos.

2. Transferencia reanudable de la replicación maestro-esclavo

A partir de redis2.8, admite la carga reanudable. Si en el proceso de replicación maestro-esclavo, la red se desconecta repentinamente, puede continuar copiando desde el lugar donde se copió la última vez en lugar de copiar desde el principio.

principio:

El nodo maestro creará una acumulación en la memoria, el maestro y el esclavo guardarán un desplazamiento de réplica y una identificación de maestro, y la compensación se guardará en la acumulación. Si la conexión de red entre el maestro y el esclavo se rompe, el esclavo permitirá que el maestro continúe replicando desde el último desplazamiento de la réplica. Pero si no se encuentra el desplazamiento, se realizará una operación de resincronización completa.

3. Copia sin disco

La replicación sin disco significa que el maestro crea directamente un archivo RDB en la memoria y lo envía al esclavo sin guardar los datos en su disco local.

Método de configuración

Configure los parámetros repl-diskless-sync y repl-diskless-sync-delay.

repl-diskless-sync: este parámetro garantiza la copia sin disco.

repl-diskless-sync-delay: este parámetro significa esperar un cierto período de tiempo antes de iniciar la replicación, para que pueda esperar a que se vuelvan a conectar varios nodos esclavos.

4. Procesamiento de claves vencidas

El esclavo no expira la clave, solo espera que el maestro expire la clave.

Si el maestro expira una clave o elimina una clave, el maestro simulará un comando del para el esclavo y el esclavo eliminará la clave después de recibirla.

Cuatro. Análisis en profundidad del proceso de flujo completo y principio de replicación de Redis

1. El proceso completo de copia

①Se inicia el nodo esclavo, solo se guarda la información del nodo maestro, incluido el host y la ip del nodo maestro, pero la replicación de datos aún no ha comenzado. El host y la ip del nodo maestro están configurados en slaveOf en el archivo redis.conf.

②Hay una tarea cronometrada dentro del nodo esclavo, que verifica cada segundo si hay un nuevo nodo maestro para conectarse a una replicación. Si se encuentra, establece una conexión de red de socket con el nodo maestro.

③ El nodo esclavo envía un comando ping al nodo maestro.

④ Si los conjuntos maestros requieren que se apruebe, el nodo esclavo debe enviar la contraseña de autenticación maestra para verificar la contraseña.

⑤El nodo maestro realiza una replicación completa por primera vez y envía todos los datos al nodo esclavo.

⑥ El nodo maestro continúa escribiendo comandos y los replica de forma asincrónica en el nodo esclavo.

2. El mecanismo de sincronización de datos

Se refiere a la situación en la que el esclavo se conecta al maestro por primera vez y realiza una replicación completa.

① Tanto el maestro como el esclavo mantienen un desplazamiento

El maestro continuará acumulando la compensación en sí mismo y el esclavo también continuará acumulando la compensación en sí mismo. El esclavo informará su compensación al maestro cada segundo, y el maestro también guardará la compensación de cada esclavo.

Esto no quiere decir que el específico se use para la replicación completa, principalmente porque el maestro y el esclavo deben conocer el desplazamiento de sus datos respectivos para conocer la inconsistencia de datos entre sí.

②retrasos

El nodo principal tiene un retraso en la memoria, que es 1 M por defecto.

Cuando el nodo maestro replica los datos en el nodo esclavo, también sincronizará los datos del backlog.

La acumulación se utiliza principalmente para la replicación incremental cuando se interrumpe la replicación completa.

③ ID de ejecución principal

Redis puede ver la identificación de ejecución maestra a través del servidor de información.

Propósito: El esclavo ubica al único maestro de acuerdo con él.

¿Por qué no usar host + ip? Porque no es confiable usar host + ip para ubicar el maestro. Si el nodo maestro se reinicia o los datos cambian, entonces el esclavo debe distinguirse de acuerdo con diferentes ID de ejecución maestra. Si la identificación de ejecución es diferente , necesita hacer la copia total de una vez.

Si necesita reiniciar redis sin cambiar el ID de ejecución, puede usar el comando redis-cli debug reload.

3. Proceso y mecanismo de copia completa

① El maestro ejecuta bgsave para generar un archivo RDB localmente.

②El nodo maestro envía el archivo de instantánea RDB al nodo esclavo. Si el tiempo de replicación del archivo RDB supera los 60 segundos (tiempo de espera de respuesta), el nodo esclavo no podrá copiar la tarea. Puede ajustar este parámetro de forma adecuada.

③Para una máquina con una tarjeta de red gigabit, generalmente se transmiten 100M por segundo, y es probable que la transmisión de archivos 6G exceda los 60 segundos.

④ Cuando el nodo maestro genera el archivo RDB, almacena en caché todos los comandos de escritura recién recibidos en la memoria. Después de que el nodo esclavo guarda el archivo RDB, estos comandos de escritura se copian en el nodo esclavo.

⑤Compruebe los parámetros esclavos de límite de búfer de salida del cliente, como [cliente-salida-búfer-límite esclavo 256 MB 64 MB 60], lo que significa que durante el período de copia, el búfer de memoria sigue consumiendo más de 64 MB o supera los 256 MB en una vez, luego deje de copiar. Error de copia.

⑥ Después de que el nodo esclavo recibe el archivo RDB, borra sus propios datos y luego vuelve a cargar el archivo RDB en su propia memoria, en este proceso proporciona servicios externos basados ​​en los datos antiguos.

⑦Si el nodo esclavo ha habilitado AOF, BRREWRITEAOF se ejecutará inmediatamente, AOF, generación de RDB, copia de RDB a través de la red, limpieza de datos antiguos esclavos, esclavo aof reescritura, lleva tiempo, si la cantidad de datos copiados está entre 4G ~ 6G, Entonces es probable que el tiempo completo de copia tarde entre 1,5 y 2 minutos.

4. Proceso y mecanismo de reproducción incremental

① Si la conexión de red entre el maestro y el esclavo se interrumpe durante la replicación completa, entonces el esclavo se vuelve a conectar al maestro para activar la replicación suplementaria.

② El maestro obtiene directamente algunos datos faltantes de su propio backlog y los envía al nodo esclavo.

③El maestro obtiene datos del backlog de acuerdo con el desplazamiento en el psync enviado por el esclavo.

5. Latido

Tanto el maestro como el esclavo se envían mensajes de latido entre sí.

El maestro lo envía cada 10 segundos de forma predeterminada y el nodo esclavo lo envía cada 1 segundo de manera predeterminada.

6. Replicación asincrónica

Cada vez que el maestro recibe el comando de escritura, ahora escribe los datos internamente y luego los envía de forma asincrónica al nodo esclavo

5. ¿Cómo lograr una alta disponibilidad del 99,99% en la arquitectura maestro-esclavo de redis?

1. ¿Qué es una alta disponibilidad del 99,99%?

Alta disponibilidad (inglés: alta disponibilidad, abreviado como HA), un término de TI, se refiere a la capacidad de un sistema para realizar sus funciones sin interrupción y representa el grado de disponibilidad del sistema. Es uno de los criterios para el diseño de sistemas. Un sistema de alta disponibilidad puede funcionar durante más tiempo que los componentes individuales que componen el sistema.

La alta disponibilidad generalmente se logra mejorando la tolerancia a fallas del sistema. Definir cómo un sistema se considera de alta disponibilidad a menudo requiere un análisis específico basado en las circunstancias específicas de cada caso.

El método de medición se basa en la comparación del daño del sistema, el tiempo inutilizable y el tiempo desde el estado inoperativo al operativo, y el tiempo total de funcionamiento del sistema. La fórmula de cálculo es:

A (disponibilidad), MTBF (tiempo medio entre fallos), MDT (tiempo medio de reparación)

Los sistemas en línea y los sistemas que realizan tareas críticas generalmente requieren que su disponibilidad alcance los 5 nueves (99,999%).

2. redis no está disponible

Redis no puede incluir la indisponibilidad de una sola instancia y la indisponibilidad de una arquitectura maestro-esclavo.

Situación no disponible:

① El nodo maestro de la arquitectura maestro-esclavo está inactivo. Si el nodo maestro está inactivo, los datos en caché ya no se pueden escribir y los datos en el esclavo no pueden caducar, lo que conduce a la indisponibilidad.

② Si es una instancia única, el proceso de redis puede morir por otras razones. O la máquina donde se implementa redis está rota.

Consecuencias de la indisponibilidad: Primero, si la caché no está disponible, la solicitud irá directamente a la base de datos. Si una gran cantidad de solicitudes excede la capacidad de carga de la base de datos, la base de datos se bloqueará. En este momento, si el problema de la caché no se puede manejar a tiempo, entonces hay demasiadas solicitudes y la base de datos se colgará poco después de reiniciarse, lo que provocará directamente que todo el sistema no esté disponible.

3. Cómo lograr una alta disponibilidad

① Asegúrese de que cada redis tenga una copia de seguridad.

② Asegúrese de que después de que falle el redis actual, pueda cambiar rápidamente al redis de respaldo.

Para solucionar este problema, se introduce el siguiente mecanismo centinela.

6. Explicación de los conocimientos básicos de la arquitectura de redis sentry

1. ¿Qué es un centinela?

Sentinal es un componente muy importante en la arquitectura del clúster de redis. Tiene principalmente las siguientes funciones:

①Monitoreo de clúster, responsable de monitorear si los procesos maestro y esclavo de redis están funcionando correctamente.

② Notificación de mensaje, si una instancia de redis es defectuosa, el centinela es responsable de enviar un mensaje como notificación de alarma al administrador.

③Failover, si el maestro cuelga, se transferirá automáticamente al esclavo.

④Centro de configuración, si ocurre una falla, notifique al cliente para que se conecte al nuevo maestro.

2. El conocimiento básico del centinela

① El centinela en sí está distribuido y debe ejecutarse como un grupo, y los centinelas trabajan juntos.

② Durante la conmutación por error, se considera que un maestro no funciona y la mayoría de los centinelas deben estar de acuerdo.

③Incluso si parte del centinela está caído, el grupo de centinelas aún puede funcionar normalmente.

④ El centinela necesita al menos 3 instancias para garantizar su robustez.

⑤ La estructura maestro-esclavo de centinela + redis no puede garantizar una pérdida de datos cero, pero solo garantiza la alta disponibilidad del clúster de redis.

⑥ En correspondencia con la arquitectura maestro-esclavo de centinela + redis, se requieren pruebas y ejercicios repetidos antes de su uso.

3. ¿Por qué el clúster centinela implementa 2 nodos no funciona correctamente?

El clúster centinela debe implementar más de 2 nodos. Si el clúster tiene solo 2 instancias centinelas implementadas, entonces quórum = 1 (la cantidad de centinelas que deben acordarse para realizar la conmutación por error).

Como se muestra en la figura, si master1 está inactivo en este momento, siempre que uno de Sentinel 1 y Sentinel 2 piense que master1 está inactivo, puede realizar una conmutación por error. Al mismo tiempo, Sentinel 1 y Sentinel 2 elegirán un centinela para realizar Conmutación por falla.

Al mismo tiempo, se requiere la mayoría (es decir, el número de más de la mitad de los centinelas en todos los grupos) en este momento. Si hay 2 centinelas, la mayoría es 2, lo que significa que al menos 2 centinelas siguen siendo ejecutándose antes de que se pueda realizar la conmutación por error.

Pero si todo el maestro y el centinela 1 están caídos al mismo tiempo, solo queda un centinela. En este momento, no hay mayoría para ejecutar y realizar la conmutación por error. Aunque todavía hay un centinela en dos máquinas extranjeras, pero 1 no puede ser mayor que 1. Es imposible garantizar más de la mitad, por lo que no se realizará la conmutación por error.

4. Clúster de centinelas clásico de 3 nodos

Configuración: quórum = 2, mayoría = 2

Si la máquina donde se encuentra M1 está inactiva, entonces quedan dos de los tres centinelas. S2 y S3 pueden acordar que el maestro está inactivo y luego elegir uno para realizar la conmutación por error.

Al mismo tiempo, la mayoría de los tres centinelas son 2, por lo que si los dos centinelas restantes están funcionando, se puede permitir la conmutación por error.

7. Problema de pérdida de datos del conmutador activo / en espera de redis sentinel: replicación asincrónica, cerebro dividido en racimo

1. Dos escenarios de pérdida de datos

①Pérdida de datos causada por replicación asincrónica

Debido a que el proceso de replicación de datos del maestro al esclavo es asíncrono, es posible que algunos datos no tengan tiempo de copiarse al esclavo. En este momento, el maestro está inactivo y esta parte de los datos se pierde.

②Pérdida de datos causada por cerebro dividido en racimo

Qué es el cerebro dividido: Cerebro dividido, es decir, una máquina en la que un maestro se desconecta repentinamente de la red normal y no puede conectarse a otras máquinas esclavas, pero de hecho el maestro todavía está funcionando.

En este momento, el centinela puede pensar que el maestro está caído y luego comenzar la elección para cambiar otros esclavos a maestro.

En este momento, habrá dos maestros en el grupo, que es el llamado cerebro dividido.

Aunque un esclavo se cambia a maestro en este momento, es posible que el cliente no haya tenido tiempo de cambiar al nuevo maestro y que los datos que continúen escribiendo en el maestro antiguo también se pierdan.

Por lo tanto, cuando el antiguo maestro se restaure nuevamente, se suspenderá como esclavo del nuevo maestro, sus propios datos se borrarán y los datos se copiarán del nuevo maestro nuevamente.

2. Resuelva la pérdida de datos causada por el cerebro dividido de la replicación asincrónica

Para resolver este problema, debe configurar dos parámetros:

min-esclavos-para-escribir 1 和 min-esclavos-max-lag :

Indica que se requiere al menos un esclavo para copiar y sincronizar datos. El retraso no puede exceder los 10 segundos.

Si una vez que todos los retrasos de sincronización y replicación de datos del esclavo superan los 10 segundos, entonces, en este momento, el maestro aceptará cualquier solicitud.

①Reduzca la pérdida de datos de la replicación asincrónica

Con la configuración de min-slaves-max-lag, se puede asegurar que una vez que el esclavo replica los datos y el retraso de confirmación es demasiado largo, se considera que se pueden perder demasiados datos después de que el maestro está inactivo y luego la escritura La solicitud es rechazada Cuando el maestro está inactivo, la pérdida de datos causada por parte de los datos que no están sincronizados con el esclavo se reduce dentro del rango controlable.

②Reduce la pérdida de datos debido a la división del cerebro

Si un maestro tiene un cerebro dividido y pierde la conexión con otros esclavos, entonces las dos configuraciones anteriores pueden garantizar que si no puede continuar enviando datos al número especificado de esclavos, y el esclavo no se envía a sí mismo un mensaje de confirmación durante más de 10 segundos, luego rechazará directamente la solicitud de escritura del Cliente.

De esta manera, el antiguo maestro después del cerebro dividido no aceptará los nuevos datos del cliente y se evitará la pérdida de datos.

La configuración anterior garantiza que si pierde la conexión con cualquier esclavo y descubre que ningún esclavo lo ha recibido después de 10 segundos, la nueva solicitud de escritura será rechazada.

Por lo tanto, en un escenario de cerebro dividido, se pierden hasta 10 segundos de datos

8. Análisis en profundidad de múltiples principios básicos subyacentes de redis sentry (incluido el algoritmo de elección de esclavos)

1.sdown y odown dos estados

Sdown es un tiempo de inactividad subjetivo, si un centinela siente que un maestro está caído, es un tiempo de inactividad subjetivo.

Odown es un tiempo de inactividad objetivo. Si los centinelas del número de quórum sienten que un maestro está caído, entonces es un tiempo de inactividad objetivo.

La condición lograda por sdown es muy simple: si un centinela hace ping a un maestro y se excede el número de milisegundos especificado por is-master-down-after-milliseconds, el maestro se considera subjetivamente inactivo.

Las condiciones para la conversión de sdown a odown son simples. Si un centinela recibe un número específico de quórum dentro de un tiempo específico y otros centinelas también piensan que el maestro está caído, entonces se considera que está caído y el maestro se considera objetivamente abajo.

2. Mecanismo de descubrimiento de campo del grupo centinela

① El descubrimiento mutuo de centinelas se realiza a través del sistema pub / subs de redis. Cada centinela enviará un mensaje al __sentinel __: hola canal. En este momento, otros centinelas pueden consumir este mensaje y percibir a otros centinelas. La presencia.

②Cada dos segundos, cada centinela enviará un mensaje al __sentinel __: hola canal correspondiente a un determinado maestro + esclavo monitoreado por él. El contenido es su propio host, ip e id de ejecución, así como la configuración de monitoreo de este maestro.

③ Cada centinela también monitoreará el __sentinel __: hola canal correspondiente a cada maestro + esclavo monitoreado por él, y luego detectará la existencia de otros centinelas que también están monitoreando este maestro + esclavo.

④ Cada centinela también intercambiará la configuración de monitoreo del maestro de acuerdo con otros centinelas y sincronizará la configuración de monitoreo entre sí.

3. Autocorrección de la configuración del esclavo

El centinela será responsable de corregir automáticamente algunas configuraciones del esclavo. Por ejemplo, si el esclavo va a convertirse en un candidato maestro potencial, el centinela se asegurará de que el esclavo esté replicando los datos maestros existentes; si el esclavo está conectado a un maestro, como después de una conmutación por error, el centinela se asegurará de que estén conectados al maestro correcto.

4. Algoritmo electoral

Si se considera que un maestro está caído, y la mayoría de los centinelas pueden cambiar entre activo y en espera, entonces un cierto centinela realizará el cambio entre activo y en espera. En este momento, primero se debe elegir un esclavo. La elección tendrá en cuenta las siguientes circunstancias:

①La cantidad de tiempo que el esclavo se desconecta del maestro

② Prioridad esclava

③La compensación de los datos de copia esclava

④La identificación de ejecución del esclavo

En primer lugar, si un esclavo se desconecta del maestro más de 10 veces la baja después de milisegundos, más el tiempo que el maestro está inactivo, entonces el esclavo no se considera adecuado para ser elegido como maestro.

Es decir: tiempo de desconexión> (hacia abajo después de milisegundos * 10 + milisegundos_since_master_is_in_SDOWN_state).

Los esclavos restantes se clasifican de acuerdo con las siguientes regulaciones:

①Primero, ordene según la prioridad del esclavo, cuanto menor sea la prioridad del esclavo, mayor será la prioridad.

② Si la prioridad es la misma, entonces depende del desplazamiento de la réplica. Cuantos más datos replica el esclavo, menor es el desplazamiento, mayor es la prioridad.

③Si desea lo mismo que el anterior, elija el esclavo con el ID de ejecución más pequeño.

5.quórum y mayoría

Cada vez que un centinela cambia entre activo y en espera, el número de quórum de centinelas debe considerarse inactivo, y luego se elige un centinela para cambiar entre activo y en espera. Este centinela debe ser autorizado por la mayor cantidad de centinelas antes de que el cambio pueda ser ejecutado oficialmente.

Si el quórum <mayoría, por ejemplo, si hay 5 centinelas, la mayoría es 3 (más de la mitad) y el quórum se establece en 2, entonces se requieren 3 centinelas para obtener autorización para realizar el cambio.

Si el quórum> = mayoría, entonces el número de centinelas en el quórum debe estar autorizado para cambiar. Por ejemplo, si hay 5 centinelas y el quórum es 5, entonces los 5 centinelas deben aceptar autorizar antes de cambiar.

6 época de configuración

El centinela monitoreará un conjunto de redis maestro + esclavo y tendrá las configuraciones de monitoreo correspondientes.

El centinela que realiza el cambio obtendrá una época de configuración del nuevo maestro (salve-> maestro) al que se cambiará. Este es un número de versión, y el número de versión debe ser único cada vez que se cambia.

Si el cambio del primer centinela elegido falla, los otros centinelas esperarán el tiempo de espera de la conmutación por error y luego tomarán el control para continuar con el cambio. En este momento, se volverá a adquirir una nueva época de configuración como el nuevo número de versión.

7, extensión de la configuración

Después de que el centinela complete el cambio, actualizará y generará la última configuración maestra localmente, y luego la sincronizará con otros centinelas a través del mecanismo de mensaje pub / sub mencionado anteriormente.

El número de versión anterior aquí es muy importante, porque varios mensajes se lanzan y monitorean a través de un canal, por lo que después de que un centinela completa un nuevo cambio, la nueva configuración maestra sigue al nuevo número de versión.

Los otros centinelas actualizan su configuración maestra según el tamaño del número de versión.

Supongo que te gusta

Origin blog.csdn.net/Linuxhus/article/details/113139049
Recomendado
Clasificación