Persistencia de Redis y replicación maestro-esclavo

¿Por qué necesitamos persistencia?

Redis es una base de datos NoSQL basada en memoria. La velocidad de lectura y escritura es naturalmente rápida, pero la memoria es instantánea. Después de cerrar o reiniciar el servicio redis, los datos almacenados en la memoria por redis se perderán. Para resolver este problema, redis proporciona dos tipos de persistencia: forma de recuperar datos después de una falla.

Opciones de persistencia

Redis proporciona dos métodos de persistencia diferentes para almacenar datos en el disco duro. Uno es el método de instantánea (también llamado método RDB), que puede almacenar todos los datos que existen en redis en cualquier momento en el disco duro; el otro es el método de solo adjuntar archivos (AOF), que copia regularmente todos los datos. ejecutado por redis Write comandos en el disco duro. Estos dos métodos de persistencia tienen sus propios méritos y se pueden utilizar al mismo tiempo o de forma independiente, y en algunos casos no se pueden utilizar ninguno.

Camino RDB

El método RDB también se denomina método de instantánea, que guarda una copia de los datos (.rdb) en un momento determinado en el disco duro mediante la creación de una instantánea. Después de reiniciar el servidor, redis cargará el archivo RDB para restaurar los datos. Echemos un vistazo a la configuración de persistencia de RDB.
vi redis.confAbra el archivo de configuración de redis, busque la sección SNAPSHOTTING y busque lo siguiente:

save 900 1
save 300 10
save 60 10000
……
dbfilename dump.rdb
dir ./

Descripción

1. guardar segundos cambios: indica que después de segundos, si hay muchos cambios con la tecla de cambios, se guardará una instantánea. Como puede ver, la persistencia rdb está habilitada de forma predeterminada y se configuran tres opciones de guardado.Si desea desactivar la persistencia rdb, simplemente comente todos los guardados.
2. dbfilename: nombre de archivo rdb
3. dir: ruta de almacenamiento de archivos RDB

Crea una instantánea

BGSAVE: El
BGSAVE comando se puede usar para crear una instantánea. Después de que redis recibe el BGSAVEcomando, se realizará un proceso secundario. El proceso secundario es responsable de escribir la instantánea en el disco duro, mientras que el proceso principal continúa procesando la solicitud de comando. Cabe señalar que redis bloqueará el proceso padre al crear un proceso hijo, y la cantidad de tiempo es proporcional al tamaño de la memoria ocupada por redis.
Además de invocar BGSAVEcomandos manualmente , BGSAVEexisten dos condiciones de activación para los comandos de la siguiente manera:

1. El usuario ha configurado la opción de guardar. A partir de la última instantánea creada por redis, se activará un BGSAVEcomando cuando se cumplan las condiciones de cualquier opción de guardar .
2. Durante la conexión de replicación maestro-esclavo, el servidor esclavo recién conectado enviará un SYNCcomando al servidor maestro para solicitar la sincronización de datos. Después de que el servidor maestro reciba el SYNCcomando, ejecutará el BGSAVEcomando una vez y luego enviará el archivo rdb generado al servidor esclavo para la sincronización de datos.

GUARDAR: Los
SAVE comandos también pueden crear una instantánea, pero a diferencia de los BGSAVEcomandos, los SAVEcomandos no crean procesos secundarios, por lo que SAVEel servidor de redis que recibe el comando no responderá a ningún otro comando hasta que se cree la instantánea. Dado que ningún otro proceso toma recursos durante el proceso de creación de una instantánea, el SAVEcomando para crear una instantánea será más rápido que el BGSAVEcomando para crear una instantánea. Aun así, los SAVEcomandos no se usan comúnmente y generalmente solo se usan cuando no hay suficiente memoria o esperando que se complete la instantánea.
Por ejemplo, cuando redis recibe un SHUTDOWNcomando para cerrar el servicio, ejecutará el SAVEcomando una vez , bloqueará a todos los clientes y lo SAVEcerrará después de que se ejecute el comando.

Las ventajas y desventajas del método RDB.

Ventaja:

1. Use solo un archivo para hacer una copia de seguridad de los datos, fácil de restaurar después de un desastre
2. En comparación con aof, el archivo rdb es más pequeño y la carga del archivo rdb para restaurar los datos también es más rápida

Desventajas:

1. Si el servicio redis se apaga o reinicia debido a una falla, los datos escritos después de que se creó la instantánea más reciente se perderán
2. Cuando la cantidad de datos es grande, la creación de un proceso hijo hará que redis se detenga durante un tiempo prolongado.

Método AOF

En pocas palabras, la persistencia AOF escribirá el comando de escritura ejecutado al final del archivo aof para registrar los cambios en los datos. Por lo tanto, redis puede restaurar los datos siempre que todos los comandos de escritura contenidos en el archivo aof se ejecuten nuevamente desde el principio hasta el final.

Abra el archivo de configuración de redis para ver:

# 是否开启aof持久化，默认为关闭（no）
appendonly yes
# 设置对aof文件的同步频率
# 每接收到一条写命令就进行一次同步，数据保障最有力，但对性能影响十分严重
appendfsync always
# 每秒进行一次同步，推荐
appendfsync everysec
# 由操作系统来决定何时进行同步
appendfsync no
# 重写aof相关
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Reescribir / comprimir archivos AOF

Dado que aof persistence registrará continuamente los comandos de escritura de redis, a medida que se ejecuta redis, el archivo aof se hará cada vez más grande, ocupando demasiado espacio en el disco duro y aumentando el tiempo para que redis realice operaciones de restauración de datos. Por tanto, es necesario tener un esquema de control para evitar archivos AOF excesivamente grandes.

BGREWRITEAOFRedis proporciona comandos para reescribir el archivo AOF y BGREWRITEAOFreducirá el tamaño del archivo AOF tanto como sea posible al eliminar los comandos redundantes en el archivo AOF original. BGREWRITEAOFEl principio de funcionamiento es BGSAVEmuy similar. Redis creará un proceso hijo, y luego el proceso hijo reescribirá el archivo aof.

Por supuesto, los BGREWRITEAOFcomandos también tienen un mecanismo de disparo automático, que se puede ejecutar automáticamente a través de la configuración auto-aof-rewrite-percentagey auto-aof-rewrite-min-size. Por ejemplo, si se configuran auto-aof-rewrite-percent 100 y auto-aof-rewrite-min-size 64mb, y aof persistence está activado, entonces el tamaño del archivo aof es mayor que 64mb y el archivo actual es mayor que el volumen de archivo después de la última reescritura Cuando sea más del doble (100%), redis ejecutará automáticamente el BGREWRITEAOFcomando.

Los pros y los contras de la persistencia AOF

Ventaja

1. La ventana de tiempo para la pérdida de datos se puede reducir a 1 segundo y no afectará demasiado al rendimiento.
2. Aof usa el modo de adición para el archivo de registro, por lo que incluso si hay un tiempo de inactividad durante el proceso de escritura, no destruirá el contenido existente en el archivo de registro; si solo se escribe la mitad de los datos, se desactivará. se inicia la próxima vez, las redis-check-aodherramientas se pueden utilizar para resolver el problema de la coherencia de los datos

Desventaja

1. El tamaño del archivo AOF siempre ha sido el mayor defecto en la persistencia AOF, incluso si existe un mecanismo para reescribir el archivo AOF.
2. El proceso de carga del archivo aof para recuperar datos llevará más tiempo que cargar el archivo rdb

Replicación maestro-esclavo

Aunque redis tiene un rendimiento excelente, todavía encuentra el problema de no poder procesar las solicitudes rápidamente. Para resistir los problemas de rendimiento de la base de datos causados ​​por la alta concurrencia, redis puede realizar la replicación maestro-esclavo y la separación de lectura y escritura como una base de datos relacional. Es decir, para escribir datos en el servidor principal, el servidor esclavo recibe actualizaciones en tiempo real y utiliza el servidor esclavo para procesar todas las solicitudes de lectura, en lugar de enviar todas las solicitudes de lectura al servidor maestro como antes, lo que provoca una presión excesiva sobre el maestro. servidor, por lo general leer solicitudes. Elegirá aleatoriamente qué servidor esclavo usar, de modo que la carga se distribuya uniformemente a cada servidor esclavo. La siguiente figura es una arquitectura simple maestro-esclavo de redis.

Configuración de replicación maestro-esclavo

Primero ejecute en su directorio redis, vi redis6380.confcree un archivo de configuración redis en el directorio actual y escriba lo siguiente:

include /usr/local/redis-4.0.13/redis.conf
port 6380
pidfile /var/run/redis_6380.pid
logfile 6380.log
dbfilename dump6380.rdb

Descripción:

1. incluir: Introduzca la información de configuración del archivo de configuración apuntado en el archivo de configuración actual. Aquí se introduce el archivo de configuración predeterminado de redis. Se han establecido el acceso remoto, la contraseña, etc., y no es necesario restablecerlo en la nueva configuración expediente. Para la información de configuración que necesita ser reconfigurada (como el número de puerto), la configuración debajo de la línea de inclusión puede anular la configuración a la que se hace referencia.
2. puerto: número de puerto, nuestros servidores maestro y esclavo se ejecutan en la misma máquina virtual, por lo que debemos configurar diferentes números de puerto.
3. pidfile: archivo pid personalizado, el pid del programa en segundo plano se almacena en este archivo.
4. logfile: archivo de registro.
5. dbfilename: el nombre del archivo rdb.

Después de las operaciones anteriores, se configura un nuevo servidor maestro, luego se configura el servidor esclavo y también se crea un archivo de configuración de redis llamado redis6382 en el directorio actualvi redis6382.conf

include /usr/local/redis-4.0.13/redis.conf
port 6382
pidfile /var/run/redis_6382.pid
logfile 6382.log
dbfilename dump6382.rdb
slaveof 127.0.0.1 6380
masterauth 主服务器的密码

Hay algunas configuraciones adicionales del servidor:

1. slaveof: indica de quién soy el servidor esclavo, necesito desarrollar la dirección IP y el número de puerto del servidor maestro
2. masterauth: si su servidor maestro está configurado con una contraseña, debe configurarlo aquí, de lo contrario, el servidor esclavo no podrá conectarse al servidor maestro

La configuración de otros servidores esclavos es similar, preste atención a la asignación de números de puerto, he configurado un 6384 aquí.
Después de que la configuración sea exitosa, utilícelo en el directorio src para ./redis-server ../redis6380.confiniciar el servidor maestro, y luego inicie el servidor esclavo y conéctese automáticamente al servidor maestro. Preste atención a especificar el archivo de configuración correspondiente.
Si ps -ef | grep redisve el siguiente contenido, significa que el servidor maestro-esclavo se ha iniciado correctamente:

root      2625     1  0 16:15 ?        00:00:00 ./redis-server *:6380
root      2630     1  0 16:15 ?        00:00:00 ./redis-server *:6382
root      2636     1  0 16:15 ?        00:00:00 ./redis-server *:6384

Después de que se inicien los servidores maestro y esclavo, ingrese el cliente del servidor maestro ./redis-cli -p 6380 -a 你的密码y ejecute info replicationpara ver la información de los servidores maestro y esclavo, de la siguiente manera

127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6382,state=online,offset=336,lag=1
slave1:ip=127.0.0.1,port=6384,state=online,offset=336,lag=1
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:336
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:336

Del mismo modo, ejecute el comando anterior desde el cliente del servidor, también puede obtener información

127.0.0.1:6384> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:686
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:b5c68a979b28d2a9ef53476510758b5d1795418b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:686
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:15
repl_backlog_histlen:672

En este punto, se ha configurado e iniciado correctamente una arquitectura redis con un maestro y dos esclavos y separación de lectura y escritura.

El proceso de inicio de la replicación maestro-esclavo

La figura anterior es el proceso de inicio del antiguo moderador y esclavo Redis. Los puntos que necesitan una explicación especial son:

1. Cuando el servidor esclavo realiza la conexión inicial, todos los datos originales de la base de datos se perderán y serán reemplazados por los datos enviados por el servidor maestro.
2. El servidor esclavo no es responsable de la operación de expiración de la clave, pero acepta pasivamente el comando enviado por el servidor maestro. Cuando un maestro expira una clave (o la expulsa debido al algoritmo LRU), sintetizará un comando DEL y lo transmitirá a todo esclavo
3. SYNC es una operación que consume muchos recursos. Durante BGSAVE, el rendimiento total del servidor maestro disminuye y luego consume una gran cantidad de recursos de red de los servidores maestro y esclavo para transmitir el archivo rdb. Cuando el servidor esclavo carga el archivo rdb , no podrá responder a la solicitud del cliente; pero el mayor defecto de SYNC es que cuando el servidor esclavo se desconecta y se vuelve a conectar, no hay necesidad de solicitar un archivo RDB para cargar nuevamente desde el principio, porque la mayoría de Es probable que los datos contenidos en este nuevo archivo RDB hayan sido escritos antes de la desconexión Desde el servidor, en este momento, el servidor esclavo solo necesita obtener los datos escritos durante la desconexión.

Resincronización parcial

Para compensar las deficiencias de la versión anterior de replicación, Redis ha utilizado el comando PSYNC en lugar del comando SYNC desde la versión 2.8. PSYNC tiene dos modos: resincronización completa y resincronización parcial, la resincronización completa es similar a la versión anterior de sincronización y se debe enviar un RDB. Pero la resincronización parcial es sorprendente: solo puede enviar comandos de escritura escritos al servidor maestro durante el período de desconexión al servidor esclavo, que consume menos recursos y es mucho más rápido. Como se muestra abajo.

El principio de implementación de la resincronización parcial no es complicado y consta de tres partes: compensación de copia (compensación), búfer de registro de copias e identificación de ejecución del servidor (runid)

Desplazamiento de
replicación El desplazamiento de replicación se utiliza para confirmar el estado de sincronización de los servidores maestro y esclavo. Los servidores maestro y esclavo mantienen cada uno un desplazamiento de copia. Cuando el servidor maestro envía N bytes de datos al servidor esclavo, agrega su propio desplazamiento de copia a N; el servidor esclavo recibe N bytes de datos. Agregue N a su propio desplazamiento de copia . El estado de sincronización se puede confirmar fácilmente comparando el desplazamiento de replicación del maestro y el esclavo.

Copia retraso buffer El
búfer de copia retraso es una longitud fija primero en entrar, primero en salir cola mantenida por el servidor maestro Cuando las preformas servidor maestro comando de propagación, el comando se pondrá en cola en la memoria intermedia retraso copia, como sigue:.

Debido a la acumulación de copias El búfer es una cola de longitud fija, por lo que solo guarda los comandos de escritura ejecutados en el período de tiempo más reciente y registra el desplazamiento de copia correspondiente para cada byte en la cola. Al enviar el comando PSYNC desde el servidor, llevará su propio desplazamiento de copia. El servidor maestro toma este desplazamiento para verificar el desplazamiento + 1 (el siguiente comando ejecutado después de la desconexión) en su propio búfer de copia de reserva. ¿Estás en la cola ? Si todavía está allí, significa que se puede realizar una resincronización parcial, y todos los datos desde el desplazamiento + 1 hasta el final de la cola se enviarán al servidor esclavo; si no lo está, el servidor esclavo solo puede realizar una resincronización completa honestamente.

Id. En
ejecución del servidor El Id. En ejecución del servidor es simplemente para ver si los servidores maestro y esclavo están en la misma familia antes de la desconexión. Cada servidor redis tiene su propia identificación de ejecución. Cuando el maestro-esclavo se conecta por primera vez, el servidor maestro enviará su propia identificación de ejecución del servidor al servidor esclavo para guardarla. Cuando el servidor esclavo se vuelva a conectar, enviará simultáneamente el anterior runid del servidor maestro guardado. Para el servidor principal, el servidor principal comparará este runid con su propio runid. Si son iguales, significa que el servidor esclavo se desconectó de sí mismo antes, y luego verifique el desplazamiento; si es inconsistente, significa que el servidor esclavo era previamente esclavo de otro servidor maestro, así que solo llame para hacer una resincronización completa.

Puede info replicationver el ID de ejecución del servidor y el desplazamiento de replicación cuando ejecuta el comando antes .

En resumen, el proceso de sincronización de una nueva versión de la replicación de redis es aproximadamente el siguiente: