Redis buffer cache como la herramienta más utilizada está dispuesto a utilizar los principales fabricantes. Por lo general, usamos los servicios de aplicaciones Redis monómero como caché, con el fin de asegurar su disponibilidad también utilizará el modo maestro-esclavo (Master-Slave), o se trata de lectura distintos y diseño de escritura. Sin embargo, al aumentar la cantidad de caché de datos, la caché no puede ser portador de servicio, tiene que ser ampliado con el almacenamiento en caché del servidor de servicios de monómero. La necesidad de la corredera de datos en diferentes particiones, dividir los datos en diferentes servidores, una memoria caché distribuida de acceso a la caché portador altamente concurrente. Redis programa Cluster sólo pasa a apoyar esta parte de la función.
Hoy a echar un vistazo a la base de los principios y la práctica de Redis Cluster:
- Redis Cluster lograr partición de datos
- La comunicación entre el nodo de caché distribuida
- Distribuido caché de encaminamiento de petición
- expansión nodo Cache y contracción
- La detección de fallos y recuperación
Redis Cluster lograr partición de datos
Como se ha mencionado en el párrafo inicial, una base de datos distribuida es a resolver por el bloque de datos, de acuerdo con las reglas asignadas a una pluralidad de nodos de almacenamiento en caché, un gran número de individual dirigida problemas de procesamiento de nodo de caché.
Si desea dividir los datos, y se almacena allí debe haber un algoritmo. Por ejemplo: la consistencia y el algoritmo de hash Hash Algorithm, estos algoritmos más clásicos.
Redis Cluster continuación, utiliza un algoritmo de partición ranura virtual. Que se refiere al concepto de la ranura (Slot) es. Esta ranura se utiliza para almacenar las unidades de información de caché en el espacio de almacenamiento se dividirá en Redis 16384 ranuras, es decir, la ranura es la gama Cluster Redis 0-16383 (2 * 4 ^ 2 ^ 10).
Almacenamiento en caché de información de valores-clave se utiliza generalmente para almacenar la forma, en el momento de almacenar la información, el clúster será clave y CRC16 cheque modulo 16384 (slot = CRC16 (clave)% 16 383).
El resultado es el valor-clave en la ranura, de tal modo realizando datos segmentación automática a diferentes nodos. Estas ranuras asignan a diferentes nodos almacenados en la caché. 
Figura 1: rebanada de datos del clúster Redis
1, se supone que hay tres nodos 1,2,3 caché. Redis Cluster se almacenará en la ranura de datos de caché (Slot) se colocaron en estos tres nodos:
nodo cache 1 se almacena (0-5000) datos de ranura.
2 se almacena en los datos Slot nodo cache (5001-10000).
3 se almacena en los datos Slot nodo cache (10000-16383).
En este momento Redis cliente necesidad de datos adquieren correspondientes a un valor de clave se calcula primer valor por CRC16 ranura (clave)% 16383, 5002 se calcula sobre el resultado suposición.
Estos datos se transmitirá al Cluster Redis, después de un cúmulo recibirá una tabla para buscar esta ranura = 5002 pertenecen al nodo de caché.
Encontrado pertenecer a "nodo de almacenamiento en caché de 2", entonces la llamada a lo largo de la dirección del contenido nodo línea de caché rojo almacena en la clave-valor de 2 y devuelto a la Redis Client.
La comunicación entre el nodo de caché distribuida
Si decimos que Redis Cluster del algoritmo de ranura virtual para resolver el problema es dividir los datos y la tienda, a continuación, almacenar en caché los datos entre los nodos es la forma de comunicarse, es decir, el siguiente que tenemos que discutir.
nodo Cache almacenamiento en caché de los datos almacenados en la implementación distribuida Redis Cluster, los nodos de almacenamiento en caché son asignados a uno o varios servidores. 
Figura 2: un nuevo almacenamiento en caché en línea nodo 2 y el nodo 1 comunicarse caché
El número de nodo de la memoria caché puede ampliarse también de acuerdo con la cantidad de datos tamponada y el apoyo concurrente. 2, se supone en el presente Cluster Redis "almacenamiento en caché de nodo 1", esta vez debido a la expansión de nuevos negocios "tampón de Nodo 2".
El nuevo nodo se añadirá a la vieja nodo, emitió un "Meet el mensaje" por el protocolo chisme. Después de recibir el mensaje de "nodo de caché 1", cortésmente responder con un "mensaje Pong".
Desde entonces "Caché Nodo 2" se enviará periódicamente a la "caché nodo 1", un "mensaje Ping," igual "caché nodo 1" cada vez respuesta "mensaje Pong".
El ejemplo anterior ilustra que la comunicación se realiza mediante protocolo Redis Cluster chisme entre los nodos de caché.
De hecho, el propósito de la comunicación entre los nodos es mantener la información de metadatos entre los nodos. Estos metadatos es que cada nodo contiene qué datos, si se produce un fallo.
Entre los nodos constantemente interactúan entre sí a través de la información de protocolo chisme, al igual que un grupo de personas, como un chisme, no se necesita mucho tiempo para conocer cada nodo a todos los demás nodos del caso, esta situación es un nodo de metadatos.
El proceso de transmisión se divide a grandes rasgos en la siguiente:
la Redis el Cluster cada nodo de almacenamiento en caché se abrirá una canales TCP separadas para la comunicación con otros nodos.
Un nodo a intervalos de tiempo regulares se seleccionará "nodo de transmisión" del sistema. Este "nodo emisor" de acuerdo con una cierta frecuencia, por ejemplo: 5 veces por segundo mensaje Ping, al azar a los iniciados nodo el más largo no de comunicación.
Recibido nodo mensaje de ping-pong utilizará el mensaje a "nodo emisor" como respuesta.
Repitiendo el comportamiento anterior, por lo que todos los nodos mantienen comunicación. La comunicación entre ellos es por el protocolo chisme.
Desde el cual se divide en cuatro tipos, a saber:
mensaje Meet para informar al nuevo nodo se añade. Conoce a enviar un mensaje si la línea dará a los antiguos nodos en el nuevo nodo en el ejemplo mencionado anteriormente, representan el "nuevo miembro" a unirse.
mensaje Ping, el mensaje de uso más frecuente, el mensaje se encapsula y el estado de su propio nodo a otros nodos en los datos, a otros nodos con regularidad.
Pong mensaje, después de recibir los mensajes Conoce y Ping también se enviarán a los propios datos de otro Estado. Pero también puede iniciar transmisiones a todos los nodos del clúster, para informarle de su estado.
Despiste mensaje, si un nodo o fuera de línea colgó, difunde el mensaje a la agrupación. 
La figura 3: arquitectura de protocolo de Gossip
estructura de protocolo de Gossip muestra en la Figura 3, en el que hay Tipo Define el tipo de mensaje, por ejemplo: mensaje Meet, Ping, Pong, Falla similares.
Además, hay una serie de myslots definir el nodo de información ranura es responsable. Cada nodo envía protocolo chisme a otros nodos es la información más importante que otros nodos. Por otra parte, el mensaje ensayo transmitida por el cuerpo del mensaje clusterMsgData objeto.
Distribuido caché de encaminamiento de petición
Internamente, los nodos de almacenamiento en caché distribuido envían mensajes entre sí a través del protocolo chisme, con el fin de garantizar entre nodos entender la situación de cada uno.
Así Externamente, un Redis cómo el cliente obtiene los datos a través de un nodo de caché distribuida se distribuye caché de enrutamiento para resolver el problema.
La transmisión de información ranura mencionada anteriormente cotilleará gestión del protocolo de cada nodo a otros nodos, que utiliza myslots unsigned char [CLUSTER_SLOTS / 8] Tal una matriz de información del nodo de almacenamiento de cada ranura.
myslots grupo de atributos es un dígito binario (matriz de bits), en el que CLUSTER_SLOTS 16.384.
La longitud de esta matriz es 16384/8 = 2048 bytes, ya que cada byte contiene bits 8 bits (dígitos binarios), que contiene un total de 16.384 bits, es decir, 16384 bits.
Cada nodo con un bit de datos para identificar si usted tiene una ranura. 4, esta figura muestra un caso se supone que el nodo A de Groove administrado. 
Figura 4: información ranura almacenada por una matriz binaria
0,1,2 tres subíndice representa 0,1,2 tres ranuras Será, si el valor binario correspondiente es 1, indica que el nodo es responsable de almacenar los datos de tres ranuras 0,1,2. Del mismo modo, detrás de la matriz de bits subíndice 0 indica que el nodo no puede ser responsable de almacenar los datos correspondientes ranura.
Advantage se almacena en binario, de alta eficiencia se determina, por ejemplo, se determina un número de ranuras, tanto tiempo como el nodo de la segunda secuencia, la complejidad de tiempo es O (1). 
Figura 5: el nodo de recepción correspondiente a la información de nodo almacenada en la ranura local de
5, cuando se recibe la ranura después de la información del nodo de envío del nodo, el nodo de recepción se guardar la información en una estructura clusterState local en la que la matriz se almacena Slots cada ranura corresponde a que la información del nodo. 
Fig 6: Estructura y ranura corresponde nodo ClusterStatus
Como se muestra en la figura 6, matriz de Slots ClusterState almacenada en cada índice se asigna a una ranura, cada ranura corresponde a un búfer de mensajes es el nodo clusternode.
Estos nodos se corresponderán con la existencia real de un servicio de almacenamiento en caché Redis, incluida la información y el puerto IP.
mecanismo de comunicación Redis Cluster prácticamente garantiza que cada nodo tiene una relación correspondiente a otros nodos y segmentos de datos.
clientes Redis acceso independientemente de que los nodos del clúster se pueden dirigir al nodo correspondiente, ya que cada nodo tiene un ClusterState, registra toda la correspondencia entre las ranuras y nodos.
Echemos un vistazo a cómo el cliente Redis para invocar el nodo de caché mediante el enrutamiento: 
Figura 7: solicitud de redirección MOVIL
Como se muestra en, Fig. 7 por el cliente Redis CRC16 (clave)% 16383 calcular el valor de ranura encontró necesidad de encontrar un "nodo de caché 1" leer / escribir datos, pero ya que la migración de datos de caché o las otras causas de los datos correspondientes a la ranura se migró a la "nodo de caché de 2" por encima.
Bueno, esta vez Redis cliente no puede obtener los datos del "Nodo caché 1."
Sin embargo, debido a la "caché nodo 1" se almacena en caché la información para todos los nodos del clúster, por lo que conoce estos datos se almacenan en la ranura "el almacenamiento en caché nodo 2", la solicitud de redirección se transmite a un cliente Redis movido.
Esto debe dirigir su solicitud de acceso a decirle al "nodo 2 Caché". Redis clientes reciben esta dirección, continúan visitando "Caché Nodo 2" y obtener datos.
El ejemplo anterior ilustra, la ranura de datos "nodo 1 cache" ha migrado desde el "nodo de caché 2" y, a continuación el cliente puede ir directamente a "nodo de caché 2" a los datos.
Así que si dos nodos de caché están haciendo nodos de migración de datos, en cuyo caso las solicitudes de los clientes cómo manejar la situación? 
Figura 8: ASK petición de redireccionamiento
8, el cliente Redis a la "caché nodo 1" solicitud, a continuación, "el almacenamiento en caché nodo 2" Migración de datos "nodo de caché 1" hacia adelante, si no golpear la ranura correspondiente, devolverá un peso cliente ASK solicitud de dirección y la dirección de dicho "nodo de caché de 2".
Datos del Cliente "almacenamiento en caché de nodo 2" transmite una orden al preguntar, hace falta preguntar si el "nodo de almacenamiento en caché de 2", "el almacenamiento en caché nodo 2" después de recibir el mensaje de resultado se devuelve si existen los datos.
expansión nodo Cache y contracción
Como el despliegue de un nodo de caché distribuida siempre se encontrará con problemas de memoria caché y el fracaso expansión caché. Esto puede causar problemas en la línea y la línea de montaje del nodo de caché.
Desde cada uno datos de nodo almacenada en el tanque, por lo que cuando los nodos de caché parecen cambiar estas ranuras datos se migraron a otro algoritmo de caché de nodo de acuerdo con la ranura virtual correspondiente. 
Figura 9: distribuido expansión caché
9, el clúster presentaría "almacenamiento en caché de nodo 1" y "nodo de almacenamiento en caché de 2", a continuación, "almacenamiento en caché de los nodos 3" en la línea y se añadió a la agrupación.
En este momento, de acuerdo con la ranura algoritmo virtual, un "caché nodo 1" y "nodo de almacenamiento en caché de 2" correspondiente a los datos del surco debe ser recién nodo añadido a migrar "nodos de almacenamiento en caché de 3" anteriores.
Para la expansión nodo, el nodo recién creado necesita funcionar en modo agrupado, la configuración de la mejor nuevo nodo con otros nodos en la configuración de clúster se mantiene constante.
El nuevo nodo se añade a la agrupación cuando un nodo es un huérfano y no otra comunicación nodo. Por lo tanto, se utilizará el grupo se encuentran el comando añadido al cluster.
Cualquier nodo del clúster con el fin de hacer que la implementación de la agrupación se reúnen nuevo nodo a unirse. Suponiendo que el nuevo nodo es 192.168.1.1 5002, el antiguo nodo es 192.168.1.1 5003, a continuación, ejecute el siguiente comando para agregar nuevos nodos al clúster.
192.168.1.1 5003> 5002 la agrupación se reúnen 192.168.1.1
Esta es iniciado por el nodo antiguo, un poco viejos miembros bienvenida a los nuevos miembros significan. El nuevo nodo no configurado para establecer los datos correspondientes a la ranura, que no se caché de los datos.
Si el nodo es maestro, la ranura tiene que ser datos de expansión; si los datos en el nodo es un nodo esclavo, se requiere la sincronización nodo maestro. De todos modos, quiero sincronizar los datos. 
Figura 10: Datos de nodo de proceso de migración ranura
Como se muestra en la figura 10, iniciado por la migración de datos ranura cliente entre los nodos, los datos migrados desde el nodo origen al nodo de destino:
los iniciados nodo cliente un comando para preparar la introducción de datos ranura de destino, de modo que el nodo de destino está listo para importar el canal de datos. Como se usa en el presente documento, setslot clúster {slot} importar {sourceNodeId } comandos.
Después de que el nodo de origen inicia un comando de envío, de manera que el nodo de origen está listo para moverse fuera de la ranura correspondiente a los datos. Usar la setslot grupo de mando ranura {} {importar sourceNodeId }.
En este momento, el nodo de origen está listo para migrar los datos, y antes de migrar los datos para migrar a salir. Comandos de grupo getkeysinslot {slot} {count} . Conde representa el número de la migración de la ranura.
a continuación, se lleva a cabo en el nodo de origen, migran {targetIP} {} targetPort "" 0 llaves {} {tiempo de espera de teclas} comando, la tecla de adquisición de lotes para el nodo de destino a través de la tubería.
Repetir 3 y 4 en dos pasos siguen a los datos de migrar al nodo de destino. nodo de destino para adquirir los datos migrados.
Después de la terminación del nodo de destino de migración de datos, {slot} el nodo {targetNodeId} aviso de comando de una ranura correspondiente se asigna al setslot clúster nodo de destino, y transmite esta información a otro nodo maestro de toda la red, el nodo actualiza su propia tabla de correspondencia ranura.
Dado que no es un servidor de caché de operación en línea, a continuación, una operación también está fuera de línea. Justo al lado de la línea de montaje y en línea operación opuesta a la operación, los datos a estar fuera de línea ranuras de nodo caché asignados a otros nodos en la caché primaria.
Migración proceso en línea también opera de manera similar, excepto que cuando la necesidad de notificar a otros nodos sin conexión olvidan toda la red, cuando downNodeId {} Notificar a otros nodos a través del grupo de mando olvidar.
Cuando el nodo recibe olvidar este comando sólo poner fuera de la lista de nodos de línea de montaje, no lo haría de nuevo después de este nodo envía la noticia de ping chisme.
Sin embargo, esta tabla de tiempo de espera de 60 segundos, más de este tiempo, todavía iniciará mensaje Ping al nodo.
Sin embargo, el uso de Redis-del-nodo trib.rb {host: puerto} {} donwNodeId ayuda nos comando desconectado operación.
Nodo es caso particular fuera de línea del nodo maestro, el nodo maestro se encargará de tomar el relevo de una posición correspondiente al nodo.
La detección de fallos y recuperación
Hablando frente a los nodos de almacenamiento en caché se refiere a expandirse y contraerse, habrá un modo offline nodo de caché cuando se contrae.
A veces, con el fin de ahorrar recursos, o esté previsto la línea de montaje, pero más a menudo conducir a nodo averiado no está en línea.
Hay dos maneras de determinar el fallo está fuera de línea por línea:
Subjetiva la línea de montaje: el momento en el que el nodo 1 al nodo 2 rutina de ping envía un mensaje, si el Nodo 2 trabajo retorne mensajes Pong y registros de información sobre el nodo 1.
Mientras tanto Pong mensaje recibido después de la última actualización del nodo de tiempo de comunicación 2 y el nodo será 1.
Si en este momento los dos nodos se desconecta por alguna razón, después de un período de tiempo tomará la iniciativa para conectar el nodo 1 nodo 2, si la comunicación ha fallado, el nodo 1 nodo 2 no puede ser actualizado con el último tiempo de comunicación.
En este caso se detecta el nodo tarea de tiempo 1 y el nodo 2 en el momento de comunicación excede el mejor momento para clúster de nodos de tiempo de espera, se actualizará el estado del nodo local, el nodo 2 actualizaciones de la conexión subjetiva.
Aquí es un clúster de nodo-timeout tiempo de espera de nodos delta se encuentran, si el nodo mensajes Pong más de este tiempo todavía no ha regresado obtenidos considera el nodo y colgó.
En la presente memoria se refiere a una subjetiva offline Nodo 1 Nodo 2 que hay mensajes subjetivos retorno pong, de modo que el nodo 2 fuera de línea.
El nodo 1 es sólo un punto de vista subjetivo, puede haber de red entre el nodo 1 y el nodo desconectado, pero otros nodos todavía puede comunicar y el nodo 2, y por lo tanto subjetivo la línea de montaje no representa un nodo es realmente abajo .
sin conexión Objetivo: Como nodos Redis racimo siguen comunicándose con el nodo de información fuera de línea en el clúster será difundir el mensaje a todos los nodos a través de los chismes.
El nodo en el clúster continuará recibiendo informes fuera de línea, el nodo maestro cuando la celebración de más de la mitad de la ranura marcada un nodo está desconectado subjetiva, objetiva y se desactivará el proceso de línea de montaje.
Es decir, cuando más de la mitad del nodo primario del clúster que un nodo subjetiva la línea de montaje, se iniciará este proceso.
Este proceso tiene una premisa que directamente hacia el nodo maestro, si se ignorará el nodo. Ese nodo de clúster recibe todos los demás nodos es la línea descendente subjetiva hará las siguientes cosas.
Guardar el informe en línea subjetiva a la estructura local de ClusterNode, y comprobar la línea de montaje para el momento de los informes subjetivos, si el tiempo de clúster de nodo de tiempo de espera * 2 supera ignoró este informe.
De lo contrario, cuando el informe se registra, y el número de nodos es la presentación de informes relativamente subjetiva marcado sin conexión a cabo igual al número de ranuras es mayor que el nodo maestro, se marca como fuera de línea objetivo.
Broadcast simultáneamente a un mensaje de fallo de clúster informar a todos los nodos marcados como nodo fallido offline objetivo, el mensaje que comprende el ID de nodo que ha fallado.
Desde entonces, todos los nodos en el nodo de clúster marcarán esta offline objetivo, el proceso de notificación de conmutación por error a partir de nodo de fallo de nodo, es decir, para restaurar los fallos.
Para decirlo claramente, es toda la línea media objetivo de los nodos del clúster se considera un nodo subjetiva se ha reducido, entonces el nodo está marcado como objetivo abajo.
Si un nodo es considerado como el objetivo principal es hacia abajo, usted tendrá que reemplazar el nodo maestro de su posición de un nodo seleccionado a partir del nodo.
Esta vez la línea de montaje del nodo maestro de todos los nodos se cargan con la obligación de recuperación, ya sea de estos nodos vigile regularmente la línea nodo primario.
Una vez que la línea de montaje se llevará a los siguientes procesos de recuperación:
① examen de calificación, cada nodo comprueba el tiempo de desconexión principal. Si este tiempo supera el cluster-node-tiempo de espera * cluster-esclavo-validez del factor A (a partir del factor nodo eficaz, el valor predeterminado es 10), entonces no hay conmutación por error cualificado.
Que a partir de este nodo y el nodo maestro desconectado durante demasiado tiempo, mucho tiempo sin nodo maestro de sincronización de datos, no es adecuado para convertirse en el nuevo nodo maestro, el nodo maestro ya que parte convertido de la parte posterior de otros nodos sincronizar sus datos.
② elecciones provocada por las condiciones arriba desde el nodo puede desencadenar elecciones. Pero la elección es un arranque secuencial, aquí, de acuerdo con el desplazamiento para determinar el tamaño de la copia.
El desplazamiento es el número de bytes de comando de ejecución grabados. Cada servidor primario será el propietario de la copia + N compensado, al recibir el servicio de la N bytes transmitidos al comando de servidor maestro, será trasladado a su propagación copia de N bytes del servidor asciende + N.
Copiar a compensar el mayor cuanto menor es la latencia desde el nodo, es decir, desde el nodo de comunicación y el nodo maestro con más frecuencia, el nodo de los datos anteriores se actualizará alguna, por lo que se copiará el mayor encabezado elecciones desplazamiento es desde el nodo.
③ iniciado la elección, el primero de cada nodo maestro para actualizar la era de configuración (clusterNode.configEpoch), este valor está aumentando entero.
Realizado mensajes Ping / Pong en un nodo interactiva se actualizará este valor, que se actualizarán el máximo valor a sus propias épocas de configuración.
Este valor registró versión de cada nodo y todo el clúster. Cada vez que algo importante cosas, tales como: la aparición de un nuevo nodo, el nodo de la selección. Aumentará configuración global y asignado a la era relevante del nodo maestro, que se utiliza para grabar el evento.
Para decirlo claramente actualizar este propósito valor es asegurar que todas estas piezas del "evento" nodo maestro consistente. Estamos unidos en una época de configuración (un entero), todos sabemos que esto representa un "gran evento" era.
Después de haber actualizado la era de configuración, que se quiere transmitir el autor del mensaje elecciones dentro del grupo (FAILOVER_AUTH_REQUEST). Y asegúrese de que cada nodo en la próxima elección de una época en la configuración sólo puede ser iniciado.
④ votación, sólo el nodo primario involucrado en la votación, la votación se completa cuando el nodo no es el derecho a voto, más de la mitad del nodo primario se convierte en el nuevo nodo primario por el nodo de uno.
Si no se obtiene un número suficiente de votos en el tiempo desde el nodo de clúster de nodo de tiempo de espera * 2, y este vacío elección, una segunda vuelta.
Aquí el nodo maestro recibirá votos emitidos desde otros nodos para cada candidato. En el segundo paso que conduce normalmente en este momento sería conseguir más votos del nodo, debido al tiempo que se dispara la elección anterior.
Un mayor acceso a los billetes, sino también debido a su latencia nodo propietario original y menos, en teoría, será más nuevo punto de datos.
⑤ Cuando la condición es satisfecha voto elegido desde el nodo, se activará la operación de sustitución del nodo maestro. Después de que el nuevo nodo primario no elige eliminar el nodo propietario original es responsable de las ranuras de datos, estas ranuras para añadir datos a su propio nodo.
Y transmitido de manera que otros nodos están al tanto de este asunto, nació el nuevo nodo maestro.
resumen
Este artículo proporciona una memoria caché distribuida por programa Redis Cluster como punto de partida para la partición se describen en este nodo caché escenario.
algoritmo de partición ranura virtual para asignar un bloque de datos a diferentes nodos de almacenamiento en caché y dejar que los datos para encontrar la ubicación de un nodo por correspondencia entre el nodo y la ranura.
Para nodos implementación distribuida, la necesidad de comunicación Ping, Pong, Meet, Fail protocolo chisme, lograr el propósito de intercambio de bienes necesarios.
Cuando el cliente llama al nodo de almacenamiento en caché de la memoria caché de datos para encontrar el nodo correcto por redirección MOVIDO y le pidió a la solicitud.
E introducido en la expansión y contracción de la caché hay que señalar que el flujo de procesamiento, así como la forma en la migración de datos.
Por último, sobre la manera de encontrar la avería (subjetiva y objetiva sin conexión sin conexión) y la forma de recuperar el proceso de manejo de defecto (nodos de las elecciones).