Windows compila el clúster de redis y la replicación maestro-esclavo

Debido al uso del entorno local, se construye un clúster de Redis local. Este artículo explica el establecimiento de un clúster de replicación maestro-esclavo de Redis. La plataforma utilizada es Windows, y la idea de compilación es básicamente la misma que en Linux!
(Es posible que le tome 15 minutos leer este artículo de manera intensiva y aproximadamente 5 minutos para leerlo)

Una breve introducción
a la replicación maestro-esclavo de Redis. Para que el clúster funcione normalmente incluso cuando algunos nodos están fuera de línea o no pueden comunicarse con la mayoría de los nodos del clúster, el clúster de Redis utiliza la función de replicación maestro-esclavo para los nodos: cada nodo en el clúster Hay de 1 a N réplicas, una de las cuales es la maestra y las N-1 restantes son esclavas. [De la replicación maestro-esclavo en el clúster de Redis]

Entonces, lo anterior es la replicación maestro-esclavo. En pocas palabras, un nodo maestro maestro puede tener uno o más nodos esclavos, y un esclavo puede tener múltiples esclavos. De esta manera, se forma una poderosa arquitectura de clúster de servidores multinivel.
Inserte la descripción de la imagen aquí

Entre ellos, el nodo maestro es principalmente escritura (escritura o lectura), y el nodo esclavo solo puede leer pero no escribir. [Escenario de separación de lectura-escritura]
Los datos escritos por el nodo maestro se sincronizarán (no casi en tiempo real) con el Salve, de modo que si el nodo maestro falla y los datos se pierden, se pueden restaurar a través del Salve. [Escenario de recuperación ante desastres, nota: debido a que los datos no están sincronizados en tiempo real, puede haber problemas de pérdida de datos después de recuperar datos del Salve]

En resumen: Las siguientes son algunas de las características de la replicación maestro-esclavo de redis:
1. Un maestro puede tener múltiples esclavos
2. Además de múltiples esclavos conectados al mismo maestro, los esclavos también pueden conectarse a otros esclavos para formar una estructura gráfica
3. La replicación maestro-esclavo no bloquea al maestro. Es decir, cuando uno o más esclavos y el maestro sincronizan datos por primera vez, el maestro puede continuar procesando la solicitud enviada por el cliente. Por el contrario, cuando el esclavo sincroniza los datos por primera vez, bloqueará la solicitud del cliente que no se puede procesar.
4. La replicación maestro-esclavo se puede usar para mejorar la escalabilidad del sistema. Podemos usar múltiples esclavos específicamente para las solicitudes de lectura del cliente. Por ejemplo, la operación de clasificación puede ser manejada por esclavos. También se puede utilizar para redundancia de datos simple
5. Puede deshabilitar la persistencia de datos en el maestro, simplemente comentar todas las configuraciones guardadas en el archivo de configuración maestro y luego configurar la persistencia de datos solo en el esclavo.
6. Se puede utilizar para la separación de lectura y escritura y la recuperación ante desastres.

Varios métodos comúnmente utilizados de replicación maestro-esclavo de Redis
Un maestro y dos servidores A (B, C), un maestro y dos esclavos
(descentralizados) A-B-C, B es el nodo maestro (el nodo maestro de C), también es el nodo esclavo (el nodo esclavo de A) al modo
orientado a invitados (después de que el nodo maestro esté inactivo, actualice manualmente el nodo esclavo al nodo maestro) y al modo centinela (después de que el nodo maestro esté inactivo, el nodo esclavo se actualiza automáticamente al maestro nodo)
Esta vez presento principalmente uno El maestro y el segundo servidor, y la operación de anti-invitado, se transmiten sin introducción. ¡Escribe una introducción especial después del modo centinela!

Construcción de replicación maestro-esclavo de Redis (un maestro y dos servidores)
1. Descargue el paquete de instalación de Redis del entorno de Windows y descárguelo de Baidu

2. Una vez completada la descarga, descomprima el
directorio descomprimido como se muestra en la siguiente figura:
Inserte la descripción de la imagen aquí
3. Operaciones de configuración relacionadas
(1) Después de copiar tres copias,
modifiqué el nombre de Redis localmente después de descomprimir , y se muestra el nombre de la carpeta después de copiar como sigue:

Redis-x64-3.2.100-6379
Redis-x64-3.2.100-6380
Redis-x64-3.2.100-6381

(2) ¡Modifique la
carpeta redis.windows.conf 6379 sin modificación!
Carpeta 6380, modificada como sigue:

port 6380

# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

Carpeta 6381, modificada como sigue:

port 6381
slaveof 127.0.0.1 6379

¡Asumo que todos conocen la configuración relevante de redis.xx.conf! Si no lo sabe, consulte:
Introducción al aprendizaje de Redis al archivo de configuración redis.conf

(3) ¡Agregue un script de ventana simple para facilitar el inicio rápido!
Cree uno nuevo en la carpeta redis correspondiente

startRedisServer.bat

El contenido del guión es:

@echo off
redis-server.exe redis.windows.conf
@pause

Luego cree un nuevo directorio en el mismo nivel de la carpeta redis

start6379.cmd
@echo off
cd Redis-x64-3.2.100-6379
startRedisServer.bat

Entonces 6380 y 6381 son las mismas que las operaciones anteriores. Una vez completada la operación, se muestra la siguiente figura:
Inserte la descripción de la imagen aquí
4. Inicie la prueba.
Regla de inicio: ¡inicie primero el nodo maestro y luego inicie el nodo esclavo!
(1) Puede usar el comando para iniciar
Ingrese el directorio de la carpeta correspondiente y use el comando de inicio:
(2) Use el script para iniciar
Como se muestra en la imagen de arriba, ejecute start6379.cmd,
start6380.cmd y start6381.cmd respectivamente.
(3) Si no puede iniciar tres redis en esta máquina al mismo tiempo utilizando el método anterior, consulte aquí

Inicie el Master primero. Utilice el cliente para iniciar sesión y ver la información como se muestra en la figura:
Inserte la descripción de la imagen aquí
luego inicie 6380 y 6381, y luego podrá ver: como se muestra
Inserte la descripción de la imagen aquí
en la figura. Vea la información de replicación maestro-esclavo de 6378 aquí: como se muestra
Inserte la descripción de la imagen aquí
en la figura . En el cliente 6380 y 6381, verifique la información del nodo: como se muestra en la figura.
Inserte la descripción de la imagen aquí
Pruebe la lectura y escritura, [el nodo maestro puede leer y escribir, el nodo esclavo solo puede leer y no escribir], como se muestra en la figura a continuación:
Inserte la descripción de la imagen aquí
pruebe el estado del nodo esclavo después de que se apague el nodo maestro [el nodo esclavo se puede leer y el nodo esclavo no se actualizará al nodo maestro]:

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:15
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381> get hello
"world"

Pruebe el estado del nodo esclavo después de que se reinicie el nodo maestro [el nodo esclavo aún puede conectarse al nodo maestro]:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=43,lag=0
master_repl_offset:43
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:42
127.0.0.1:6379>

Episodio [Orientado contra el cliente]
Prueba cuando el nodo maestro está apagado, no use esclavo de nadie. Sí, 6380 se convierte en el nodo maestro, pero es solo el nodo maestro, ¡sin ningún nodo esclavo! :Como se muestra

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:155
master_link_down_since_seconds:jd
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381>
127.0.0.1:6381>
127.0.0.1:6381> slave no one
(error) ERR unknown command 'slave'
127.0.0.1:6381> slaveof no one
OK
127.0.0.1:6381> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6381> set test 11
OK
127.0.0.1:6381> get test
"11"
127.0.0.1:6381>

Para obtener más información, consulte el contenido de la replicación maestro-esclavo de Redis .

El principio de la replicación maestro-esclavo de Redis La
primera introducción
Cuando se configura el servidor esclavo, el esclavo establecerá una conexión con el maestro y luego enviará el comando de sincronización.
El maestro recibe el comando para iniciar el proceso de guardado en segundo plano y, al mismo tiempo, recopila todos los comandos recibidos para modificar el conjunto de datos. Después de que se ejecuta el proceso en segundo plano, el maestro transmitirá el archivo de datos completo al esclavo para completar un sincronización.
Copia completa: después de que el servicio esclavo recibe los datos del archivo de la base de datos, los guarda y los carga en la memoria. (La primera cantidad completa)
Replicación incremental: el maestro continúa pasando todos los nuevos comandos de modificación recopilados al esclavo para completar la sincronización. (Incrementar después)
Pero mientras se vuelva a conectar el maestro, se ejecutará automáticamente una sincronización completa (replicación completa).
Cuando se configura el servidor esclavo, el esclavo establecerá una conexión con el maestro y luego enviará el comando de sincronización. Ya sea la conexión establecida por primera vez o la reconexión después de que se desconecta la conexión, el maestro iniciará un proceso en segundo plano para guardar la instantánea de la base de datos en un archivo, y el proceso maestro maestro comenzará a recopilar nuevos comandos de escritura y almacenarlos en caché. . Una vez que el proceso en segundo plano termina de escribir el archivo, el maestro envía el archivo al esclavo y el esclavo guarda el archivo en el disco y luego lo carga en la memoria para restaurar la instantánea de la base de datos al esclavo. Luego, el maestro enviará los comandos almacenados en caché al esclavo. Y los siguientes comandos de escritura recibidos por el maestro se enviarán al esclavo a través de la conexión establecida al principio. El comando para sincronizar datos del maestro al esclavo y el comando enviado desde el cliente utilizan el mismo formato de protocolo. Cuando se desconecta la conexión entre el maestro y el esclavo, el esclavo puede restablecer automáticamente la conexión. Si el maestro recibe comandos de conexión simultáneos de varios esclavos al mismo tiempo, solo iniciará un proceso para escribir la duplicación de la base de datos y luego lo enviará a todos los esclavos.

La segunda introducción: la
red de origen del contenido de la imagen: la
Inserte la descripción de la imagen aquí
tercera introducción: La
sincronización maestro-esclavo de Redis tiene dos métodos (o dos etapas): sincronización completa y sincronización parcial.
Cuando el maestro y el esclavo recién estén conectados, realice una sincronización completa; una vez finalizada la sincronización completa, realice una sincronización parcial. Por supuesto, si es necesario, Slave puede iniciar la sincronización completa en cualquier momento. La estrategia de Redis es, en cualquier caso, primero intentará realizar una sincronización parcial. Si no tiene éxito, el esclavo debe realizar una sincronización completa e iniciar BGSAVE ... Una vez finalizado BGSAVE, el archivo RDB se transfiere; si tiene éxito , el esclavo puede realizar una sincronización parcial y transferir datos en el espacio de trabajo pendiente.

Replicación maestro-esclavo de Redis (un maestro, dos esclavos / un maestro, varios esclavos) análisis de
sobretensiones de E / S.
Cada vez que el esclavo se desconecta (ya sea activamente desconectado o falla de red) y luego se conecta al maestro, todos los maestros debe ser descargado fuera de RDB, en aof, el proceso de sincronización debe ejecutarse nuevamente; por lo tanto, recuerde que varios esclavos no deben iniciarse todos a la vez, de lo contrario, el maestro puede aumentar IO bruscamente (intervalo de 1 a 2 minutos)

Retraso de replicación
Debido a que todas las operaciones de escritura se realizan primero en el maestro y luego se sincronizan con el esclavo, existe un cierto retraso en la sincronización del maestro a la máquina esclava.Cuando el sistema está muy ocupado, el problema de retraso será más serio. El número de máquinas esclavas El aumento también agravará este problema.

Baja disponibilidad
Cuando ocurre una situación anormal en el nodo maestro, no podrá escribir, lo que provocará errores comerciales. [La solución es utilizar el modo Redis-Sentinel; consulte el segundo artículo de la serie para obtener más detalles]

Nota: el
clúster de Redis no garantiza una coherencia sólida de datos (coherencia sólida) Garantía de coherencia del clúster de Redis (garantía) : En determinadas condiciones, el clúster de Redis puede perder los comandos de escritura que se han ejecutado.

————————————————
Declaración de derechos de autor: Este artículo es el artículo original del blogger de CSDN "Afeiyun", y sigue el acuerdo de derechos de autor CC 4.0 BY-SA. Adjunte la fuente original enlace y esto para reimprimir.
Enlace original: https://blog.csdn.net/u010648555/article/details/79427606

El material del autor es muy interesante, puedes ver el contenido dentro

Encontré un programador que está lleno de rabia, jajaja, puedes leer más su blog y prestarle atención

Supongo que te gusta

Origin blog.csdn.net/weixin_44887276/article/details/115031459
Recomendado
Clasificación