Estudiar dos soluciones para la alta disponibilidad de Redis
El autor del blogger codeump.codeump.info se ha dedicado al desarrollo backend de servidores de Internet durante muchos años. Visite el blog del autor para leer más artículos sobre codedump.
Para lograr alta disponibilidad (HA) en Redis, se adoptan los dos métodos siguientes:
En Redis, los datos replicados por el nodo maestro y los nodos esclavos se pueden dividir en replicación completa y copia parcial.
Utilice el comando snyc para lograr la replicación a gran escala. El proceso es el siguiente:
El mayor problema con la versión anterior de la función de replicación a gran escala es cuando el servidor. Se desconecta y luego se vuelve a conectar, incluso si algunos datos también deben copiarse por completo, lo cual es muy ineficiente, por lo que la nueva versión de Redis ha realizado mejoras en esta parte.
La nueva versión de Redis utiliza el comando psync en lugar del comando sync, que puede lograr una sincronización total y parcial.
Las dos partes que realizan la replicación, el servidor maestro y el servidor esclavo, mantienen compensaciones de replicación respectivamente:
El servidor maestro mantiene una cola FIFO de longitud fija como búfer de copia pendiente, con un tamaño predeterminado de 1 MB.
Cuando el servidor maestro propaga el comando, no solo el comando de escritura se sincronizará con el servidor esclavo, sino que el comando de escritura se escribirá en el búfer de trabajo pendiente de replicación.
Cada servidor Redis tiene su propio ID de ejecución, que el servidor genera automáticamente cuando se inicia. El servidor maestro enviará su ID de ejecución al servidor esclavo, y el servidor esclavo guardará la ID de ejecución del servidor maestro.
Cuando el servidor Redis se desconecta y se vuelve a conectar, el progreso de la sincronización se juzga en función del ID de ejecución:
Con los preparativos anteriores, comencemos a analizar el proceso del comando psync:
En los dos primeros casos, después de que el servidor principal reciba el comando psync, aparecerán las siguientes tres posibilidades:
Redis utiliza el mecanismo centinela para implementar alta disponibilidad (HA). El principio de funcionamiento general es el siguiente:
Los nodos de Redis se dividen en dos categorías:
Lo anterior es el proceso general y las siguientes preguntas deben resolverse:
Respondamos estas preguntas una por una.
El nodo Sentinel monitorea la disponibilidad del servicio de los nodos de datos de Redis a través de tres tareas de monitoreo regulares.
Cada 10 segundos, cada nodo centinela enviará el comando de información al nodo de datos principal de Redis y al nodo de datos esclavo de Redis para obtener nueva información de topología.
La información de topología de Redis incluye:
De esta manera, el nodo centinela puede obtener automáticamente la información del nodo esclavo del comando info, por lo que la información del nodo esclavo agregada más tarde se puede detectar automáticamente sin configuración explícita.
Esta operación en realidad logra dos cosas: *Descubrir un nuevo ganglio linfático centinela: si se agrega un nuevo ganglio linfático centinela, la información de este nuevo ganglio linfático centinela se guarda en este momento y luego se establece con este Se conecta el ganglio linfático centinela. *Intercambiar la información de estado del nodo maestro como base para un juicio objetivo posterior sobre si el nodo maestro está fuera de línea.
Cada 1 segundo, cada nodo centinela envía un comando de ping al maestro, a los nodos de datos esclavos y a otros nodos centinela para la detección de latidos. Esta es la base para juicios subjetivos posteriores de que el nodo de datos está fuera de línea.
Si la tercera tarea de detección de latidos entre las tres tareas de monitoreo anteriores no recibe una respuesta válida después de los milisegundos de inactividad configurados, el nodo de datos se considera "subjetivamente inactivo".
¿Por qué se llama "subjetivo sin conexión"? Debido a que en un sistema distribuido hay muchas máquinas trabajando juntas, pueden ocurrir diversas situaciones en la red.
El juicio de un solo nodo no es suficiente para considerar un nodo de datos fuera de línea, y se requiere el siguiente "objetivo fuera de línea".
Cuando un ganglio centinela cree subjetivamente que el nodo maestro está desconectado, necesita preguntar a otros ganglios centinela si el nodo maestro está desconectado mediante el comando "sentinel is-master-down-by-addr". Si más de la mitad de los ganglios centinela responden que están fuera de línea, el nodo maestro se considera "objetivamente fuera de línea".
Cuando el nodo maestro se desconecta objetivamente, es necesario elegir un ganglio centinela como líder centinela para completar el trabajo posterior de seleccionar un nuevo nodo maestro.
La idea general de esta elección es:
Como puede ver, el proceso de elección de líderes es muy similar al proceso de elección de líderes en balsa.
Entre los nodos esclavos de Redis restantes, seleccione un nuevo nodo maestro en el siguiente orden:
Después de seleccionar un nuevo nodo maestro, se requiere un proceso final para convertir el nodo en el nuevo maestro Nodo:
Dirección original:
https://www.codedump.info/post/20190409-redis-sentinel/
Lectura de referencia: p>
La Conferencia Global de Arquitectura de Internet de GIAC en la estación de Shenzhen se llevará a cabo en junio de 2019. Qian Wenpin, arquitecto senior y autor de "Redis Deep Adventure: principios básicos y prácticas de aplicación", asistirá a la estación GIAC Shenzhen en junio de 2019 como conferenciante de bases de datos para dar una conferencia sobre el alto rendimiento y la alta disponibilidad de Redis. El especial de la base de datos GIAC de este año invitó a Yu Feng, exjefe de la base de datos de Alibaba Cloud, como productor.
Únete a GIAC y haz un balance de las últimas tecnologías en 2019. Actualmente hay un 25% de descuento por compras, y hay aún más descuentos por compras múltiples. Identifique el código QR para conocer más sobre la conferencia.