Introducción y construcción del grupo centinela de Redis.

Redis es un sistema de almacenamiento de estructura de datos en memoria de código abierto que se puede utilizar como base de datos, caché y middleware de mensajería. Sin embargo, como servicio de punto único, Redis puede provocar que el servicio no esté disponible cuando se produzcan fallos de hardware o problemas de red. Para resolver este problema, Redis proporciona el modo centinela, una solución de alta disponibilidad.

En este blog, profundizaremos en el patrón Sentinel de Redis. Primero presentaremos los conceptos básicos del modo centinela, incluido el nodo maestro, el nodo esclavo y el nodo centinela. Luego, analizaremos en detalle los principales procesos en el modo Sentinel, incluidos subjetivos fuera de línea, objetivos fuera de línea, elección de líder y conmutación por error.

Si es un novato en Redis o un desarrollador experimentado, creo que este blog puede ayudarlo a comprender y utilizar mejor el modo centinela de Redis. ¡Empecemos!

---

---

1. Introducción al modo Redis Sentinel

1.1 Descripción general del modo Redis Sentinel

El modo centinela de Redis es una solución de alta disponibilidad proporcionada por Redis. Supervisa el estado de ejecución del servidor maestro y los servidores esclavos de Redis mediante el uso de nodos centinela. Cuando el servidor maestro falla, el centinela puede promover automáticamente un servidor esclavo al nuevo servidor maestro para lograr la conmutación por error.

Las siguientes son las características principales del modo Redis Sentinel:

1. Monitoreo: Sentinel verificará periódicamente si el servidor maestro y los servidores esclavos se están ejecutando normalmente, incluida la verificación de si pueden responder a las solicitudes de los clientes normalmente y si la replicación de datos entre los servidores maestro y esclavo es normal.
2. Notificación: cuando Sentinel descubre que el servidor maestro ha fallado, puede enviar notificaciones al administrador a través de la API.
3. Conmutación por error automática: cuando el servidor maestro falla, Sentinel elegirá automáticamente un nuevo servidor maestro de los servidores esclavos y permitirá que otros servidores esclavos comiencen a replicar el nuevo servidor maestro.
4. Proveedor de configuración: los clientes pueden preguntar a Sentinel qué servidor es el maestro actual. De esta manera, incluso si se produce una conmutación por error, el cliente puede encontrar el servidor primario correcto.

1.2 Replicación maestro-esclavo de Redis y modo centinela

El modo de replicación maestro-esclavo es una forma común de mejorar la redundancia de datos y el rendimiento de lectura en Redis, pero también tiene algunas deficiencias:

1. Problema de punto único de falla: en el modo de replicación maestro-esclavo, todas las operaciones de escritura se realizan en el servidor maestro. Si el servidor maestro falla, todo el servicio Redis no podrá procesar las solicitudes de escritura.
2. Recuperación manual de fallas: cuando el servidor maestro falla, debe promover manualmente un servidor esclavo al nuevo servidor maestro y modificar la configuración de la aplicación para que apunte al nuevo servidor maestro. Este proceso puede tardar algún tiempo y provocar la interrupción del servicio.
3. Problema de coherencia de datos: durante el proceso de replicación de datos del servidor maestro al servidor esclavo, si ocurre un problema de red o el servidor esclavo deja de funcionar, los datos en el servidor maestro y el servidor esclavo pueden ser inconsistentes.

El modo centinela de Redis está diseñado para resolver estos problemas:

1. Conmutación por error automática: el modo Sentinel puede detectar automáticamente el estado del servidor maestro. Cuando el servidor maestro falla, el centinela elegirá automáticamente un nuevo servidor maestro de los servidores esclavos y permitirá que otros servidores esclavos comiencen a replicar el nuevo servidor maestro. Este proceso es automático y no requiere intervención manual, lo que puede reducir el tiempo de interrupción del servicio causado por fallas del servidor principal;
2. Evite puntos únicos de falla: el modo Sentinel evita puntos únicos de falla mediante la conmutación por error automática. Incluso si el servidor principal falla, el servicio Redis aún puede continuar procesando solicitudes de escritura;
3. Notificación: Sentinel puede enviar los resultados de la conmutación por error al cliente;
4. Proporcionar función de descubrimiento de servicios: Sentinel también proporciona una función de descubrimiento de servicios. El cliente puede preguntarle a Sentinel qué servidor maestro actual es, de modo que incluso si ocurre una conmutación por error, el cliente pueda encontrar el servidor maestro correcto.

1.3 Funciones principales del modo centinela de Redis

En el modo centinela de Redis, hay tres roles principales:

1. Maestro: el nodo maestro es el principal proveedor de servicios de Redis, maneja todas las operaciones de escritura y copia datos en los nodos esclavos. En circunstancias normales, todas las operaciones de lectura y escritura son manejadas por el nodo maestro;
2. Esclavo: el nodo esclavo es la copia de seguridad del nodo maestro, copia datos del nodo maestro y puede manejar operaciones de lectura. Cuando el nodo maestro falla, el nodo esclavo puede ascender al nuevo nodo maestro;
3. Nodo centinela (Sentinel): el nodo centinela es la clave para la alta disponibilidad de Redis. Supervisa el estado de ejecución del nodo maestro y los nodos esclavos. Cuando el nodo maestro falla, el nodo centinela realizará una conmutación por error, elegirá un nuevo nodo maestro y se reconfigurará. el nodo esclavo.nodo.

En el modo centinela, puede haber varios nodos maestros, nodos esclavos y nodos centinela para formar un servicio Redis distribuido y de alta disponibilidad.

---

2. Principio del modo centinela de Redis

El modo Sentinel utiliza nodos centinela para completar la supervisión, la conexión y la conmutación por error de los nodos de datos.

2.1 Monitoreo de sincronización del modo centinela de Redis

El nodo centinela verificará periódicamente el estado de ejecución del servidor maestro y de todos los servidores esclavos, incluido si están en línea, si pueden responder a las solicitudes normalmente, si la replicación de datos maestro-esclavo es normal, etc.

Los siguientes son los pasos principales para el monitoreo programado en modo centinela:

1. Cada 1 segundo (predeterminado), cada nodo Sentinel envía un comando PING al nodo maestro, a los nodos esclavos y a los nodos Sentinel restantes para verificar si están en línea. Si el servidor responde normalmente al comando PING, el nodo centinela considera que el servidor está en línea. Si el servidor no responde o devuelve un error, el nodo centinela piensa que el servidor puede haber fallado;
2. Cada 2 segundos (predeterminado), cada nodo Sentinel enviará un mensaje al __sentinel__:hellocanal del nodo de datos de Redis, que contiene el juicio del nodo Sentinel sobre el nodo maestro y la información del nodo Sentinel actual;
3. Cada 10 segundos (predeterminado), cada nodo Sentinel enviará periódicamente (el valor predeterminado es cada 10 segundos) comandos INFO al nodo maestro y a todos los nodos esclavos para obtener la topología más reciente y otra información. El comando INFO puede devolver diversa información y estadísticas del servidor Redis, incluida información general del servidor (como la versión de Redis, tiempo de inicio, sistema operativo, etc.), información de conexión del cliente, uso de memoria, estado de persistencia de datos, maestro-esclavo. Información copiada, etc.

2.2 Modo Redis Sentinel: descarga subjetiva y objetiva

En el modo centinela de Redis, "subjetivo fuera de línea" y "objetivo fuera de línea" son dos conceptos importantes que son la base para que el nodo Sentinel determine si el servidor principal ha fallado.

Inactividad subjetiva: cada nodo Sentinel enviará periódicamente (el valor predeterminado es cada 1 segundo) comandos PING al nodo maestro, a los nodos esclavos y a otros nodos Sentinel para la detección de latidos. Si un nodo down-after-millisecondsno responde efectivamente dentro del tiempo establecido por los parámetros, el nodo Sentinel determinará la falla del nodo, este comportamiento se denomina subjetivo fuera de línea.

La conexión subjetiva fuera de línea se basa en el juicio de la propia perspectiva del nodo Sentinel y solo significa que el nodo Sentinel no puede comunicarse normalmente con el nodo detectado, lo que puede deberse a problemas de red o una falla real del nodo detectado.

Objetivo inactivo: cuando suficientes nodos Sentinel creen que el servidor principal ha estado fuera de línea, se considera que el servidor principal está objetivamente fuera de línea. Este es el consenso de la mayoría de los nodos centinela y es más creíble.

En el modo centinela de Redis, cuando un nodo Sentinel determina subjetivamente que el nodo maestro está fuera de línea, solicitará sentinel is-master-down-by-addra otros nodos Sentinel su opinión sobre el nodo maestro mediante comandos. Si la respuesta recibida indica que la cantidad de nodos Sentinel que piensan que el nodo maestro está fuera de línea alcanza quorumel valor establecido por el parámetro, entonces el nodo Sentinel pensará que efectivamente hay un problema con el nodo maestro y tomará una decisión objetiva de desconectarse. .

En el modo Sentinel, el proceso de conmutación por error se activará solo cuando se considere que el servidor principal está objetivamente fuera de línea. Esto es para evitar falsos positivos debido a problemas de red o errores de juicio de nodos Sentinel individuales. Solo cuando la mayoría de los nodos Sentinel crean que el servidor principal está fuera de línea, esto se considerará una falla real y se requerirá una conmutación por error.

2.4 Elección del nodo del modo Sentinel de Redis

En el modo centinela de Redis, cuando se considera que el nodo maestro está objetivamente fuera de línea, el nodo centinela llevará a cabo una elección de líder y seleccionará un nodo centinela líder para que sea responsable del proceso de conmutación por error. Los siguientes son los pasos detallados para la elección del líder del nodo centinela:

1. Iniciar elección: cuando un nodo Sentinel determina que el nodo maestro está objetivamente fuera de línea, iniciará un nuevo proceso de elección de líder. Primero, incrementa su época de configuración (un número creciente global) y luego envía un mensaje solicitando una votación a otros nodos Sentinel;
2. Votación: cuando un nodo Sentinel recibe un mensaje solicitando votación, si la época de configuración en la solicitud es mayor que su propia época de configuración, actualizará su propia época de configuración y enviará un mensaje de votación al nodo Sentinel que solicita la votación. Cada nodo Sentinel solo puede votar una vez en una época de configuración;
3. Votación estadística: el nodo Sentinel que solicita la votación contará los mensajes de votación recibidos. Si recibe votos de la mayoría de los nodos Sentinel dentro del tiempo especificado (el valor predeterminado es 2 segundos), será elegido líder;
4. Iniciar conmutación por error: el nodo Sentinel líder iniciará el proceso de conmutación por error, incluida la elección de un nuevo nodo maestro, la reconfiguración de los nodos esclavos, etc.

A través de este proceso, el sistema Sentinel puede elegir rápidamente un líder para la conmutación por error después de que falla el nodo maestro, lo que garantiza la alta disponibilidad del servicio Redis.

2.5 Modo Redis Sentinel: conmutación por error

En el modo centinela de Redis, cuando se considera que el nodo maestro está objetivamente fuera de línea, el nodo centinela realizará una conmutación por error, elegirá un nuevo nodo maestro y reconfigurará el nodo esclavo. Estos son los pasos detallados para la conmutación por error:

1. Elija un nuevo nodo maestro: Primero, el nodo Sentinel líder elegirá un nuevo nodo maestro entre todos los nodos esclavos. El principio de elección es dar prioridad al nodo esclavo con los datos más recientes (el mayor desplazamiento de replicación) y la mayor prioridad.
2. Enviar el comando ESCLAVO DE NADIE: El nodo centinela líder enviará el comando al nodo maestro recién elegido SLAVEOF NO ONEpara convertirlo en el nuevo nodo maestro.
3. SLAVEOFReconfigure el nodo esclavo: el nodo Sentinel líder enviará comandos a los otros nodos esclavos para convertirlos en nodos esclavos del nuevo nodo maestro.
4. Actualizar metadatos: finalmente, todos los nodos Sentinel actualizarán sus propios metadatos, incluida la dirección del nodo maestro, la relación maestro-esclavo, etc.
5. Notificar a los clientes: todos los nodos Sentinel enviarán +switch-mastermensajes a los clientes que se hayan suscrito al evento, notificándoles que el nodo principal ha sido cambiado.

A través de este proceso, el sistema Sentinel puede completar rápidamente la conmutación por error después de que falla el nodo maestro, lo que garantiza la alta disponibilidad del servicio Redis.

---

3. Implementación de replicación maestro-esclavo de Redis

3.1 Extraer la imagen de Redis

Extraiga la imagen de Redis:

docker pull redis

3.3. Cree las carpetas requeridas

Cree las carpetas necesarias para asignar las rutas de archivo correspondientes del contenedor:

mkdir -p ~/data/redis/master/data                                  
touch ~/data/redis/master/redis.confmkdir                       
touch ~/data/redis/master/redis.conf 
mkdir -p ~/data/redis/slave-1/data       
touch ~/data/redis/slave-1/redis.confmkdir
touch ~/data/redis/slave-1/redis.conf
mkdir -p ~/data/redis/slave-2/data       
touch ~/data/redis/slave-2/redis.confmkdir
touch ~/data/redis/slave-2/redis.conf 
mkdir -p ~/data/redis/slave-3/data       
touch ~/data/redis/slave-3/redis.confmkdir
touch ~/data/redis/slave-3/redis.conf 
# sentinel.conf 文件一个就够
touch ~/data/redis/master/sentinel.conf   			

3.3 Modificar redis.conf

Modificar el archivo redis.conf del nodo maestro

bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no 
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes 

Modificar el archivo redis.conf del nodo esclavo

bind 0.0.0.0
# 开启保护模式，限制为本地访问，默认yes
protected-mode no 
# 默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程，改为yes会使配置文件方式启动redis失败
daemonize no
# redis持久化（可选）
appendonly yes 
# 指向master节点
replicaof 172.17.0.2 6379

3.4 Modificar sentinel.conf

Modificar el archivo sentinel.conf

daemonize yes
sentinel monitor mymaster 172.17.0.2 6379 2
port 26379

4.5 Ejecutar el contenedor

Ejecute el contenedor y especifique la ruta de montaje:

docker run -p 16379:6379 -p 16389:26379 --name redis-master -v ~/data/redis/master/data/:/data -v ~/data/redis/master/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/master/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run -p 26379:6379  -p 16390:26379 --name redis-slave-1 -v ~/data/redis/slave-1/data/:/data -v ~/data/redis/slave-1/sentinel.conf:/etc/redis/sentinel.conf -v ~/data/redis/slave-1/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run  -p 36379:6379  -p 16391:26379 --name redis-slave-2 -v ~/data/redis/slave-2/data/:/data -v ~/data/redis/slave-2/sentinel.conf:/etc/redis/sentinel.conf  -v ~/data/redis/slave-2/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes
---
docker run  -p 46379:6379  -p 16392:26379 --name redis-slave-3 -v ~/data/redis/slave-3/data/:/data -v ~/data/redis/slave-3/sentinel.conf:/etc/redis/sentinel.conf  -v ~/data/redis/slave-3/redis.conf:/etc/redis/redis.conf -d redis redis-server /etc/redis/redis.conf --appendonly yes

Ver a través de Docker Desktop:

4.6 Ver información del nodo maestro-esclavo

Ver información del nodo maestro-esclavo:

# 进入从节点服务
docker exec -it [CONTAINER ID] redis-cli
# 查看角色信息
127.0.0.1:6379> role
# 查看主从复制信息
127.0.0.1:6379> info replication

Nodo maestro:

Desde el nodo: