El principio del clúster de Redis
Redis Cluster implementa todas las operaciones de una sola clave. Para operaciones de múltiples claves, la clave debe estar ubicada en un nodo y Redis Cluster determina en qué ranura se almacena la clave mediante etiquetas hash.
La función principal de un nodo es almacenar datos, el estado del clúster y asignar claves a los nodos correspondientes. Automáticamente descubre otros nodos, encuentra nodos fallidos y convierte al nodo esclavo en maestro.
Para lograr estas funciones, el clúster utiliza protocolos tcp y binarios (bus de clúster Redis) para realizar la interconexión entre nodos. Los nodos también utilizan el protocolo gossip para difundir información, incluido el descubrimiento de nodos, el envío de paquetes ping y mensajes Pub/Sub.
Dado que el nodo no actúa como un proxy de reenvío para solicitudes, devuelve errores MOVED y ASk y los clientes pueden conectarse directamente a otros nodos. Pero en la práctica, el cliente almacena un mapeo de claves a nodos para mejorar el rendimiento.
Redis Cluster utiliza un modelo de replicación asincrónica, es decir, el nodo seleccionado como nodo maestro durante el proceso de conmutación por error sobrescribe otros nodos de réplica con sus propios datos. Entonces, siempre hay un momento en el que un puerto perderá datos.
El siguiente es un ejemplo de pérdida de datos:
La partición primaria deja de estar disponible
Una de sus particiones esclavas se convierte en la partición primaria
> Después de un cierto período de tiempo, la partición primaria vuelve a estar disponible
Antes de que la partición primaria se convierta en una partición secundaria, los clientes todavía usan la ruta anterior para escribir solicitudes en la partición primaria.
3. Disponibilidad
Supongamos que hay n nodos maestros, cada nodo maestro está instalado bajo un nodo esclavo y el clúster todavía está disponible en el punto de suspensión uno. Punto de suspensión dos, la disponibilidad es 1 - (1/(n 2 - 1)) (después de suspender el primer nodo, quedan n 2-1 nodos), y la probabilidad de que el nodo maestro de solo un nodo sea suspendido es 1 /n*2 -1)
La migración de replicación aumenta la disponibilidad
4. Rendimiento
El clúster reids no envía solicitudes al nodo correcto y le dice al cliente el nodo correcto
El cliente guardará la última clave en la asignación de nodos. En circunstancias normales, el cliente accederá directamente al nodo correcto.
Replicación de escritura asincrónica
El rendimiento de las operaciones generales es el mismo que el de un solo redis, mientras que el rendimiento de un clúster con n nodos maestros es cercano a n* un solo redis
En resumen Como se mencionó, el alto rendimiento, la expansión lineal, la seguridad de escritura razonable y la alta disponibilidad son los principales objetivos de rediscluser.
Porque, en primer lugar, la cantidad de datos almacenados en redis será particularmente grande y se necesitará más espacio si se fusiona.
La distribución del espacio de claves se divide en 16384 ranuras, por lo que es un clúster y el número máximo de nodos maestros es 16384 (generalmente se recomienda). el número máximo de nodos maestros es 1000)
HASH_SLOT = CRC16(key) mod 16384
La función de la etiqueta hash es garantizar que se puedan distribuir diferentes claves en la misma ranura para realizar operaciones de múltiples teclas
La función de la etiqueta hash La regla es comenzar desde el primero { y terminar con el primero}, y el contenido en el medio tiene hash.
Ejemplo
{user1000}.following usa {user1000}.followers user1000 como clave
foo{}{bar} toda la clave
{{bar}} tiene {user1000}.followers user1000 como clave.
{bar como clave
{bar}{zap} barra como clave
Ejemplo de Ruby
De izquierda a derecha: ID de nodo, dirección: puerto, bandera, El último ping enviado, el último pong recibido, tiempo de configuración, estado del enlace, ranura
Entre ellos, la identificación del nodo es una cadena aleatoria de 160 bytes obtenida cuando se inicia por primera vez. Esta identificación se guarda en el. archivo de configuración y nunca se utilizará. Sin cambios
Cada nodo tiene un puerto TCP adicional que se utiliza para intercambiar información con otros nodos. Por ejemplo, si el puerto del cliente es 6379, el puerto del bus del clúster es 16379.
La comunicación entre nodos se logra a través del bus del clúster y del protocolo del bus del clúster. El protocolo de bus de clúster es un protocolo binario que no está documentado públicamente ya que otras aplicaciones no se recomiendan oficialmente para comunicarse con nodos de Redis, por lo que hay que consultar el código fuente para verlo.
Un clúster de Redis es una estructura de malla en la que cada nodo está conectado a otros nodos a través de TCP. Si hay n nodos en el clúster, cada nodo tiene n-1 enlaces salientes y n-1 enlaces entrantes. Estos enlaces son siempre válidos. Si un nodo envía un ping, no recibirá un ping, pero aún no es el momento de hacer que el nodo sea inalcanzable y actualizará el enlace reconectándose.
El nodo siempre aceptará conexiones en el puerto del bus del clúster y responderá a los pings, incluso si el nodo al que se hace ping no es de confianza. Sin embargo, si el remitente no es miembro del clúster, se descartarán otros paquetes.
Hay dos formas para que los nodos acepten otros nodos como miembros del clúster.
De esta manera, siempre que agreguemos un nodo a un nodo, otros nodos lo descubrirán automáticamente.
El cliente es libre de conectarse a cualquier nodo, si el nodo no puede manejarlo, devolverá un error MOVED como se muestra a continuación
Describe la ranura hash de la clave, que pertenece a Nodos
El cliente mantiene un mapeo de ranuras hash a IP: mapeo de puertos
Cuando se recibe un error de movimiento, se puede acceder a través de nodos del clúster (CLUSTER NODES) o ranuras del clúster ( CLUSTER SLOTS) Actualiza todo el cliente
El clúster admite la adición y eliminación de nodos en el estado de ejecución. Agregar o quitar abstracción de nodo: mueve parte de una ranura hash de un nodo a otro.
Entonces, el núcleo del escalado dinámico es mover ranuras hash entre nodos, y las ranuras hash son colecciones de claves. Por lo tanto, compartir consiste en mover claves de un nodo a otro.
redis proporciona los siguientes comandos:
Los dos primeros comandos, ADDSLOTS y DELSLOTS, se utilizan para asignar o eliminar ranuras para el nodo actual. Estos dos comandos pueden aceptar múltiples valores de ranura. Asignar una ranura significa notificar al nodo maestro designado (es decir, este comando debe ejecutarse en el nodo maestro), que se hará cargo del servicio de la ranura correspondiente después de que se asigne la ranura, y esta información se enviará a otros nodos; en el racimo a través del chisme.
El comando ADDSLOTS se utiliza normalmente al crear un nuevo clúster. La directiva ADDSLOTS se utiliza normalmente al crear un nuevo clúster que consta de varios maestros vacíos, después de lo cual el administrador debe asignar manualmente ranuras a cada maestro y asignar las 16384 ranuras para que el clúster funcione correctamente. En resumen, ADDSLOTS solo se puede ejecutar en ranuras que aún no están asignadas (es decir, que no están en manos de ningún nodo), generalmente hacemos esto cuando creamos un nuevo clúster o reparamos un clúster roto (donde algunas ranuras se pierden debido a una falla permanente del nodo). eso cuando. Para evitar errores, Redis Cluster proporciona un asistente redis-trib que nos permite completar estas tareas fácilmente.
Si las ranuras especificadas están ubicadas en el nodo actual y las ranuras eliminadas están en el estado "no asignado" (sus datos clave se han borrado), es decir, ningún nodo las sobrescribe, DELSLOTS elimina estas ranuras, lo que puede provocar que el clúster deje de estar disponible.
Esta situación puede hacer que el clúster deje de estar disponible. Este comando generalmente se usa para depurar y rara vez se usa en entornos reales. Los espacios eliminados se pueden reasignar a través de ADDSLOTS.
SETSLOT es un comando importante y el medio más importante para reasignar ranuras del clúster; se utiliza para migrar una única ranura entre dos nodos. Dependiendo de cómo opera la ranura, tiene dos estados: "MIGRANDO" e "IMPORTANDO"
1) MIGRANDO: establece el estado de la ranura en "MIGRANDO" Migrar)" y migra al nodo de destino. Tenga en cuenta que el nodo actual debe ser el titular de la ranura. Durante la migración, la operación de consulta del cliente aún se ejecuta en el nodo actual. Si la clave no existe, enviará un mensaje de redireccionamiento "-ASK" al cliente, después del cual el cliente volverá a enviar la solicitud al nodo de destino migrado.
2) Importar: establezca el estado de la ranura en "IMPORTANDO" y migre desde el nodo de origen al nodo actual, siempre que el nodo de origen sea el titular de la ranura; lo mismo que el anterior.
Si tenemos dos nodos A y B, donde el slot 8 está ubicado en el nodo A, y queremos migrar el slot 8 de A a B, podemos usar el siguiente método:
1) En el nodo B: CLUSTER SETSLOT 8 IMPORTANDO A
2) En el nodo A: CLUSTER SETSLOT 8 MIGRANDO B
Después de la migración, podemos usar el siguiente método.
Durante la migración, la información del clúster de otros nodos en el clúster no cambiará, es decir, la ranura 8 todavía corresponde a A, es decir, durante este período, las consultas de los clientes todavía están en A:
1) Si la clave existe en A, entonces A se ejecuta.
2) De lo contrario, ASK se devuelve al cliente y el cliente redirige la solicitud a B.
De esta manera, la creación de la nueva clave no se realizará en A, sino en B, que es el motivo de la redirección ASK (la clave antes de la migración está en A, y la clave creada durante migración La clave está en B); cuando se completa el SET SLOT anterior, el estado de la ranura se borrará automáticamente, la información de migración de la ranura se propagará a otros nodos, por lo que la asignación de ranuras en el clúster cambiará. y la solicitud de datos para el puesto 8 se enviará directamente a B.
Pasos para la fragmentación dinámica:
Arriba, introdujimos la redirección MOVED, que es muy similar a ASK. ¿Por qué no podemos usar MOVED durante el reparto? MOVED significa que otro nodo se ha apoderado permanentemente de la ranura hash y la siguiente consulta debe interactuar con él, mientras que ASK significa que la consulta actual interactúa temporalmente con el nodo especificado durante la migración, es posible que la clave de la ranura 8 sea; todavía en A, por lo que el cliente La solicitud del final aún debe comenzar desde A primero. Durante la migración, es posible que la clave para la ranura 8 todavía esté en A, por lo que la solicitud del cliente aún tiene que pasar por A primero, y para una clave que no existe en A, simplemente la probamos en B. Durante el proceso de migración, Redis Cluster no forzará el bloqueo de todas las solicitudes en la ranura 8 hasta que se complete la migración, lo que afectará la disponibilidad del clúster aunque ASK ya no sea necesario.
1) Cuando un cliente recibe una redirección ASK, solo redirigirá la consulta actual al nodo especificado; las solicitudes posteriores se entregarán al nodo anterior.
2) El cliente no actualiza la asignación de ranura local y aún mantiene la asignación de la ranura 8 a A hasta que se completa la migración del clúster y encuentra una redirección MOVED.
Una vez que se completa la migración de la ranura 8 (y se actualiza la información del mapa del clúster), si el cliente accede nuevamente a la ranura 8 en A, recibirá una redirección MOVED y el cliente actualizará el clúster local. información del mapa.
Es posible que algunas implementaciones de Cluster Client no mantengan las asignaciones de ranuras (es decir, nodos a ranuras) en la memoria, y cada solicitud accederá aleatoriamente a un nodo entre los nodos conocidos declarados y la información redirigida (MOVED) para encontrar el adecuado. nodo, este modo de acceso suele ser muy ineficiente.
Por supuesto, el cliente debe almacenar en caché la información de configuración de la ranura localmente si es posible, pero no se requieren actualizaciones absolutamente en tiempo real, porque si la solicitud se "redirecciona" ocasionalmente, el cliente puede reenviar la solicitud correctamente y luego La configuración de ranuras se actualiza en este momento. (Por lo tanto, los clientes normalmente no necesitan comprobar de forma intermitente si la información de configuración en el clúster se ha actualizado). Los clientes normalmente actualizan la configuración de las ranuras en todos los ámbitos:
En el caso de MOVED, no es suficiente que el cliente actualice solo ranuras específicas, ya que la observación en un clúster a menudo afecta a varias ranuras. El cliente puede obtener la información de asignación de ranuras más reciente del clúster actual enviando el comando "CLUSTER NODES" o "CLUSTER SLOTS" a cualquier nodo; la información devuelta por el comando "CLUSTER SLOTS" es más fácil de analizar para el cliente.
Normalmente, las solicitudes de lectura y escritura son manejadas por el nodo maestro que ocupa la ranura, ya que los nodos esclavos de Redis pueden admitir operaciones de lectura (siempre que la aplicación pueda tolerar datos obsoletos), los clientes pueden usar la directiva "READONLY" extendida; la operación de lectura para extender la solicitud de lectura.
"READONLY" significa que puede acceder a los nodos esclavos del clúster, puede tolerar datos obsoletos y el enlace no realizará operaciones de escritura. Cuando el enlace está configurado en modo "READONLY", el clúster solo enviará un mensaje de redireccionamiento si el maestro del esclavo no tiene la clave (es decir, la solicitud de LECTURA del cliente se enviará al maestro del esclavo La solicitud de LECTURA de la máquina). siempre se envía al nodo esclavo y solo será redirigido cuando el nodo maestro del nodo esclavo no ocupa el slot. Esto es muy fácil de entender):
1) El nodo esclavo El nodo maestro sí. no ocupa la ranura correspondiente
2) El clúster se reconfigura, por ejemplo, se vuelve a fragmentar o el nodo esclavo se migra a otro nodo maestro, y el nodo esclavo en sí ya no admite la ranura.
Los nodos del clúster intercambian continuamente datos de ping y pong, que están estructurados de la misma manera que los paquetes. La estructura de los paquetes es la misma, ambos llevan información de configuración del clúster; la única diferencia es el campo de tipo en el mensaje.
Normalmente, cuando un nodo envía un mensaje ping, el receptor devolverá un mensaje pong, pero a veces este no es el caso, como cuando un nuevo nodo se une al clúster, el receptor enviará un mensaje ping; mensaje a otros nodos. mensaje pong en lugar de enviarlo directamente al remitente. La ventaja de esto es que la configuración se puede propagar por el clúster lo más rápido posible.
Normalmente, un nodo envía pings a un número aleatorio de nodos cada segundo, por lo que el número total de paquetes de ping enviados por cada nodo es constante independientemente del tamaño del clúster. Cada nodo se asegurará de enviar un ping dentro de la mitad del tiempo de espera de NODE_TIMEOUT, si es posible, a los nodos que aún no han enviado un ping ni han recibido un mensaje pong. El nodo también intentará restablecer enlaces TCP con nodos con comunicación anormal antes de que se agote el tiempo de espera de NODE_TIMEOUT para garantizar que estos nodos no se consideren inalcanzables solo porque el enlace actual es anormal.
Si el valor NODE_TIMEOUT es pequeño y hay muchos nodos en el clúster, la cantidad de información intercambiada globalmente puede ser muy grande porque cada nodo intentará enviar pings a otros nodos en la mitad del tiempo NODE_TIMEOUT. Cada nodo envía un ping a cada uno de los otros 99 nodos en 30 segundos, con un promedio de 3,3 mensajes por segundo, por lo que el volumen global de mensajes para todo el clúster es de 330 mensajes por segundo. Esta cantidad de información no tendrá un impacto grave en el ancho de banda del clúster.
Contenido de los paquetes de latidos
Los paquetes de ping y pong también contienen una parte de chismes, que le dice al receptor que el nodo actual tiene el estado de otros nodos, pero solo contiene el estado de Se conocen varios nodos aleatorios y el número de nodos depende del tamaño del clúster.
La sección Gossip contiene
Detección de fallas de clúster para conmutación por error cuando la mayoría de los nodos no pueden alcanzar un nodo maestro o esclavo y promueve el nodo esclavo apropiado al nodo maestro. Cuando la promoción de esclavos no se puede realizar de manera eficiente, el clúster entrará en un estado de error y dejará de recibir consultas de los clientes. Consulta del cliente.
Cada nodo tiene una lista de nodos conocidos, incluidas banderas. Hay dos estados de bandera: PFAIL significa "posible falla" y es un estado de falla que aún no se ha reconocido completamente (es decir, un nodo o un pocos El nodo maestro lo considera inaccesible). FAIL indica que la mayoría de los maestros del clúster han determinado que el nodo es de conmutación por error (la mayoría de los maestros han determinado que el nodo es inalcanzable y el tiempo inalcanzable ha alcanzado el valor establecido, lo que requiere conmutación por error).
ID de nodo, ip+puerto, bandera, luego el receptor determinará el estado del nodo según la vista del remitente, lo cual es muy útil para la detección de fallas y el descubrimiento automático de nodos.
Cuando no se puede acceder a un nodo durante más de NODE_TIMEOUT, el nodo se marcará como PFAIL (posiblemente fallido) y tanto el nodo maestro como el esclavo pueden marcar otros nodos como PFAIL. Inalcanzable significa que el tiempo para que un "ping activo" (enviar un ping y poder recibir un ping) tenga éxito no ha excedido NODE_TIMEOUT, por lo que configuramos el valor de NODE_TIMEOUT para que sea mayor que el tiempo de retardo de ida y vuelta de la interacción de red ( generalmente lo suficientemente grande como para ignorar el tiempo de ida y vuelta de la interacción). Para evitar falsos positivos, cuando un nodo no recibe pong dentro de la mitad del tiempo NODE_TIMEOUT, el nodo actual hará todo lo posible para restablecer la conexión e intentará nuevamente eliminar la posibilidad de no recibir pong