Introducción al clúster de Redis

Redis, como sistema de almacenamiento de estructura de datos en memoria de código abierto, ha ganado un amplio reconocimiento en la industria por su excelente rendimiento y sus ricas estructuras de datos. Sin embargo, cuando nos enfrentamos a grandes cantidades de datos y muchas solicitudes simultáneas, es posible que una sola instancia de Redis no pueda satisfacer nuestras necesidades. En este momento, necesitamos utilizar el modo de clúster de Redis. A través del modo de clúster, podemos mejorar la disponibilidad y confiabilidad de los datos y mejorar el rendimiento y la escalabilidad del sistema. En los siguientes artículos, presentaré en detalle los conceptos básicos del clúster de Redis, así como el principio de funcionamiento, la conmutación por error y la expansión del clúster de Redis.



1. Introducción al modo de clúster de Redis

1.1 Descripción general del modo de clúster de Redis

El modo de clúster de Redis es una solución distribuida proporcionada por Redis. Sentinel resuelve el problema de la alta disponibilidad y el clúster es la solución definitiva, que resuelve los problemas de alta disponibilidad y distribuidos de una sola vez. En el modo de clúster, los datos se distribuirán en varios nodos de Redis y cada nodo es responsable de almacenar una parte de toda la base de datos, este método se denomina fragmentación de datos.

Redis Cluster no utiliza hash consistente, pero introduce el concepto de ranuras hash. El clúster de Redis tiene ranuras hash 16384. Cuando es necesario colocar un par clave-valor en el clúster de Redis, Redis primero realizará un cálculo CRC16 en la clave y luego tomará el resto de 16384. El resultado es la ranura hash donde se debe colocar la llave número.

Cada nodo de Redis es responsable de una parte de las ranuras hash. Por ejemplo, en un clúster de Redis con 3 nodos, el nodo A puede ser responsable de las ranuras hash 0-5500, el nodo B puede ser responsable de las ranuras hash 5501-11000 y el nodo C puede ser responsable de 11001-Hash slot 16383.

De esta manera, cuando es necesario acceder a una clave (lectura, escritura), el clúster de Redis calculará el número de ranura hash en función del nombre de la clave y luego encontrará el nodo responsable de la ranura hash.

imagen-20230911114418005

El clúster de Redis admite el modo de replicación maestro-esclavo. Cada nodo tendrá 0 o más nodos esclavos y los datos se copiarán del nodo maestro a los nodos esclavos. Cuando el nodo maestro deja de funcionar, el nodo esclavo puede ascender a nodo maestro y continuar brindando servicios.

El clúster de Redis proporciona alta disponibilidad y capacidades distribuidas, pero el cliente requiere cierta complejidad al usarlo, como al procesar transacciones entre nodos y scripts Lua, y redistribuir ranuras hash al agregar y eliminar nodos.

1.2 Partición de ranura virtual del clúster Redis

En el almacenamiento distribuido, los conjuntos de datos deben asignarse a varios nodos de acuerdo con las reglas de partición. Existen tres reglas de partición de datos comunes: partición del resto del nodo, partición hash consistente y partición de ranura virtual.

Partición del resto del nodo (Partición de módulo): este método asigna datos a diferentes nodos tomando el resto. Por ejemplo, podemos tomar el módulo de la ID de usuario y el número de nodos y luego almacenar los datos en el nodo correspondiente. La ventaja de este método es que es sencillo de implementar y la distribución de datos es relativamente uniforme. Sin embargo, cuando cambia la cantidad de nodos, es necesario reasignar la mayoría de los datos, lo que resulta en una gran migración de datos;

imagen-20230912143611156Partición de hash consistente: este método asigna datos a diferentes nodos a través de un algoritmo de hash consistente. La ventaja del algoritmo hash consistente es que cuando cambia la cantidad de nodos, solo es necesario migrar una pequeña parte de los datos en el anillo hash, lo que reduce en gran medida el costo de la migración de datos. Al mismo tiempo, el algoritmo hash consistente también puede garantizar una distribución de datos relativamente uniforme.

Por ejemplo, en la imagen siguiente, la Clave1 y la Clave2 caerán en el Nodo1, la Clave3 y la Clave4 caerán en el Nodo2, la Clave5 caerá en el Nodo3 y la Clave6 caerá en el Nodo4.

imagen-20230912143735383

Pero todavía tiene problemas: los nodos de caché están distribuidos de manera desigual en el anillo, lo que provocará una mayor presión sobre algunos nodos de caché; cuando un nodo falla, todos los accesos realizados por este nodo se trasladarán a otro nodo, lo que provocará fuerza en el siguiente nodo.

Partición de ranuras virtuales: este método divide el espacio de datos en múltiples ranuras virtuales y luego asigna estas ranuras virtuales a diferentes nodos. Redis Cluster utiliza el método de partición de ranuras virtuales, que divide todos los espacios clave en 16384 ranuras virtuales. La ventaja de este método es que cuando cambia el número de nodos, solo es necesario reasignar las ranuras virtuales en lugar de los datos, lo que reduce la sobrecarga de la migración de datos. Al mismo tiempo, la partición de ranuras virtuales también puede garantizar una distribución de datos relativamente uniforme.

1.3 Comandos de uso común en el clúster de Redis

Los siguientes son algunos comandos de uso común para clústeres de Redis:

  1. CLUSTER ADDSLOTS <slot> [slot ...]: agregue una o más ranuras al nodo actual.
  2. CLUSTER COUNT-FAILURE-REPORTS <node-id>: Devuelve el número de informes de fallos de otros nodos al nodo especificado.
  3. CLUSTER COUNTKEYSINSLOT <slot>: Devuelve el número de pares clave-valor en la ranura especificada.
  4. CLUSTER DELSLOTS <slot> [slot ...]: elimina una o más ranuras en el nodo actual.
  5. CLUSTER FAILOVER [FORCE|TAKEOVER]: Activa manualmente la conmutación por error; si se especifica FORCEo TAKEOVER, no es necesario esperar la autorización de otros nodos.
  6. CLUSTER FLUSHSLOTS: Elimina toda la información de ranura del nodo actual.
  7. CLUSTER FORGET <node-id>:Eliminar un nodo del clúster.
  8. CLUSTER GETKEYSINSLOT <slot> <count>: Devuelve algunas claves en la ranura especificada.
  9. CLUSTER INFO: Devuelve información del clúster.
  10. CLUSTER KEYSLOT <key>: En qué ranura se debe colocar la llave de retorno.
  11. CLUSTER MEET <ip> <port>: agregue un nuevo nodo al clúster.
  12. CLUSTER NODES: Devuelve información sobre todos los nodos del clúster.
  13. CLUSTER REPLICATE <node-id>: establece el nodo actual como el nodo esclavo del nodo especificado.
  14. CLUSTER RESET [HARD|SOFT]:Restablece el nodo actual.
  15. CLUSTER SAVECONFIG: guarde la configuración del nodo en el disco.
  16. CLUSTER SET-CONFIG-EPOCH <epoch>: establece la época de configuración del nodo.
  17. CLUSTER SETSLOT <slot> <subcommand> [node-id]: establece el estado de la ranura.
  18. CLUSTER SLAVES <node-id>: Devuelve todos los nodos esclavos del nodo especificado.
  19. CLUSTER SLOTS: Devuelve información sobre todas las ranuras del clúster.

2. Principio del modo de clúster de Redis

2.1 Creación de clústeres

Existen los siguientes pasos al crear un clúster de Redis:

  1. Iniciar nodo: inicie el servicio Redis en cada nodo preestablecido. La cantidad mínima de nodos en el modo de clúster de Redis es 3, y estos 3 son todos nodos maestros. Esto es para cumplir con los requisitos mínimos de alta disponibilidad de Redis Cluster, es decir, en caso de falla del nodo maestro, la conmutación por error puede ocurrir a través de otros nodos maestros. Sin embargo, en esta configuración, si falla un nodo maestro, el clúster no podrá proporcionar servicios porque no habrá suficientes nodos maestros para lograr la mayoría. Por lo tanto, para garantizar una alta disponibilidad, generalmente se recomienda tener al menos 6 nodos, incluidos 3 nodos maestros y 3 nodos esclavos.
  2. Creación de un clúster: también llamado protocolo de enlace de nodos, se refiere al proceso de establecer contacto entre nodos en el clúster de Redis, comunicándose a través del protocolo Gossip. Cuando un nuevo nodo necesita unirse al clúster, enviará un comando a cualquier nodo del clúster CLUSTER MEET, incluida su propia dirección IP y número de puerto. El nodo que recibe el comando actualizará su tabla de nodos y propagará la información del nuevo nodo a otros nodos en el clúster a través del protocolo gossip. De esta manera, se completa el protocolo de enlace del nodo y el nuevo nodo se une exitosamente al clúster;

imagen-20230912170433776

  1. Asignación de espacios: en el clúster de Redis, todos los datos se asignarán a 16384 espacios. Cada nodo es responsable de una parte de las ranuras, y solo cuando a un nodo se le asigna una ranura puede procesar comandos para las claves asociadas con esas ranuras. Al crear un clúster o ajustar la estructura del clúster, puede usar CLUSTER ADDSLOTSel comando para asignar ranuras a los nodos;
  2. Establezca la relación maestro-esclavo: si hay varios nodos en el clúster, debe configurar la relación maestro-esclavo para lograr una copia de seguridad de los datos y una alta disponibilidad.
2.2 Descubrimiento de fallos

En un clúster de Redis, los nodos se comunican entre sí mediante el envío de mensajes ping/pong, que forma parte del protocolo de chismes. Cada nodo enviará periódicamente mensajes ping a otros nodos. Si cluster-node-timeoutno se recibe un mensaje pong de un nodo dentro del tiempo, se considerará que el nodo ha fallado y se marcará como un estado subjetivo fuera de línea (pfail).

imagen-20230912172646206

Cuando un nodo se marca como subjetivamente fuera de línea, esta información se propagará en el clúster a través del protocolo de chismes. Cuando más de la mitad de los nodos maestros marcan un nodo como subjetivamente fuera de línea, el nodo se marcará como objetivamente fuera de línea (falla), lo que desencadenará el proceso de conmutación por error.

imagen-20230912172851058

2.3 Conmutación por error

Cuando falla un nodo maestro, otros nodos maestros en el clúster detectarán la falla a través del protocolo de chismes. Estos nodos maestros luego elegirán uno de los nodos esclavos del nodo maestro fallido para reemplazar al nodo maestro fallido. Este proceso se denomina conmutación por error.

Este método es algo similar a la conmutación por error del modo centinela de Redis, pero en el modo centinela, solo el nodo centinela participará en el proceso de detección de fallas y conmutación por error, mientras que en el modo de clúster, todos los nodos maestros participarán en este proceso. Esto puede mejorar la eficiencia de la conmutación por error y reducir el tiempo de recuperación ante fallos.

El proceso específico es el siguiente:

  1. Verificación de elegibilidad: todos los nodos esclavos del nodo maestro fallido verificarán la hora de su última comunicación con el nodo maestro para determinar si están calificados para reemplazar el nodo maestro fallido.

  2. Tiempo de preparación para la elección: un nodo esclavo que sea elegible para la conmutación por error establecerá un tiempo para la elección fallida. Solo después de alcanzar este tiempo se podrá iniciar el proceso de elección.

  3. Iniciar una elección: cuando la tarea programada del nodo esclavo detecta que ha llegado el momento de la elección fallida (failover_auth_time), se iniciará el proceso de elección.

  4. Votación electoral: el nodo maestro que ocupa el espacio procesará el mensaje de elección fallida y votará. Cada nodo maestro que ocupa un espacio solo puede votar por un nodo esclavo en cada época de configuración, lo que garantiza que solo un nodo esclavo pueda obtener más de la mitad de los votos.

  5. Elegir un nuevo nodo maestro: El nodo esclavo que obtenga más de la mitad de los votos será elegido como nuevo nodo maestro.

  6. Notificar al clúster: el nuevo nodo maestro enviará un mensaje a otros nodos del clúster para notificarles que ha sido seleccionado como el nuevo nodo maestro.

  7. Actualizar la asignación de ranuras: el nuevo nodo maestro se hará cargo de todas las ranuras del nodo maestro fallido y otros nodos del clúster actualizarán su propia información de asignación de ranuras después de recibir mensajes del nuevo nodo maestro.

  8. Comience a brindar servicios: el nuevo nodo maestro comienza a brindar servicios y maneja las solicitudes de los clientes. Este proceso garantiza que cuando falla el nodo maestro, el clúster pueda realizar una conmutación por error rápidamente y mejora la disponibilidad del clúster.

En un clúster de Redis, el proceso de conmutación por error requiere los votos de más de la mitad de los nodos maestros. Si no hay suficientes nodos maestros en el clúster, o si se implementan varios nodos maestros en la misma máquina y no pueden funcionar correctamente, no se podrán recopilar suficientes votos y el proceso de conmutación por error fallará.

Por lo tanto, para evitar puntos únicos de falla, cuando implementamos un clúster de Redis, debemos intentar asegurarnos de que todos los nodos maestros estén distribuidos en diferentes máquinas físicas. De esta forma, incluso si una determinada máquina física falla, no afectará a más de la mitad de los nodos maestros, asegurando la alta disponibilidad del clúster.

2.4 Expansión del cluster

Cuando la carga del clúster de Redis es demasiado alta o el espacio de almacenamiento es insuficiente, la capacidad se puede ampliar agregando nuevos nodos. Después de agregar un nuevo nodo, es necesario migrar algunas ranuras al nuevo nodo para que el nuevo nodo pueda comenzar a brindar servicios. Este proceso se puede CLUSTER ADDSLOTSrealizar mediante el comando.

Durante el proceso de expansión, los administradores o el personal de operación y mantenimiento deben enviar comandos al clúster a través de la herramienta de línea de comandos de Redis (redis-cli) u otras herramientas de administración para realizar operaciones como agregar nuevos nodos, asignar ranuras y migrar ranuras.

El proceso de expansión del clúster Redis incluye principalmente los siguientes pasos:

  1. Agregue un nuevo nodo: primero, debemos iniciar una instancia de Redis en el nuevo servidor y agregarla al clúster de Redis existente. Esto CLUSTER MEETse puede hacer mediante el comando.
  2. Asignar ranuras: luego, debemos asignar una parte de las ranuras para el nuevo nodo. Esto CLUSTER ADDSLOTSse puede hacer mediante el comando.
  3. Ranura de migración: a continuación, debemos migrar algunos datos del nodo antiguo al nuevo. Esto CLUSTER MIGRATESLOTse puede hacer mediante el comando. Durante este proceso, la ranura migrada no estará disponible temporalmente.
  4. Actualizar el mapeo de espacios: finalmente, necesitamos actualizar la información de mapeo de espacios de todos los nodos en el clúster para informarles la nueva asignación de espacios. Esto CLUSTER NODESse puede hacer mediante el comando.

Lo anterior es el proceso de expansión del clúster Redis. Cabe señalar que este proceso puede afectar los servicios del clúster, porque durante el proceso de migración de espacios, los espacios migrados no podrán proporcionar servicios temporalmente. Por lo tanto, cuando realizamos operaciones de expansión de capacidad, debemos hacer todo lo posible para realizarlas cuando la carga es baja para reducir el impacto en los servicios.

2.5 Reducción de conglomerados

Cuando la carga del clúster de Redis es demasiado baja o hay demasiados recursos inactivos, puede reducir la capacidad eliminando algunos nodos. Antes de eliminar un nodo, debe migrar todas las ranuras de este nodo a otros nodos y luego eliminar este nodo. Este proceso se puede CLUSTER DELSLOTSrealizar mediante el comando.

El proceso de reducción del clúster Redis incluye principalmente los siguientes pasos:

  1. Migración de datos: primero, debemos migrar todos los datos del nodo que deben reducirse a otros nodos del clúster. Esto CLUSTER MIGRATESLOTse puede hacer mediante el comando. Durante este proceso, la ranura migrada no estará disponible temporalmente.
  2. Eliminar ranuras: luego debemos eliminar todas las ranuras en el nodo que debe reducirse. Esto CLUSTER DELSLOTSse puede hacer mediante el comando.
  3. Eliminar nodos: finalmente, debemos eliminar los nodos que deben reducirse del clúster. Esto CLUSTER FORGETse puede hacer mediante el comando.

Supongo que te gusta

Origin blog.csdn.net/weixin_45187434/article/details/132837721
Recomendado
Clasificación