¿Qué problemas resuelve principalmente redis?
1. Instantánea de la memoria de escritura principal
El comando guardar programa la función rdbSave, que bloqueará el trabajo del hilo principal. Cuando la instantánea es grande, puede tener un gran impacto en el rendimiento y pausar los servicios de forma intermitente. Por lo tanto, es mejor que el maestro no escriba instantáneas de la memoria.
2. AOF Master Perseverance
Si el archivo AOF no se reescribe, este método de persistencia tiene un impacto mínimo en el rendimiento, pero el archivo AOF seguirá creciendo y el exceso de archivos AOF lo hará. afectar la velocidad de recuperación del reinicio principal.
3. El host llama a BGREWRITEAOF
El maestro llama a BGREWRITEAOF para reescribir el archivo AOF. Al reescribir, ocupará muchos recursos de CPU y memoria, lo que provocará una gran carga de servicio. Corto tiempo de pausa del servicio.
La siguiente es la situación de un proyecto mío real. La situación general es la siguiente: un maestro, cuatro esclavos, sin mecanismo de fragmentación, solo separación de lectura y escritura, el maestro es responsable de las operaciones de escritura y la copia de seguridad del registro AOF, el archivo AOF es de aproximadamente 5G y el esclavo es responsable de las operaciones de lectura . Cuando el maestro llama a BGREWRITEAOF, la carga en el maestro y el esclavo aumentará repentinamente de manera dramática. Básicamente no hubo respuesta a la solicitud de escritura del maestro, que duró unos 5 minutos. La solicitud de lectura del esclavo llega demasiado tarde para responder a tiempo. El diagrama de carga del servidor maestro y del servidor esclavo es el siguiente:
Carga del servidor maestro:
Carga del servidor esclavo:
La situación anterior no sucederá y No es posible, porque la máquina que estaba previamente controlada era una máquina esclava y había una tarea del temporizador de shell llamada BGREWRITEAOF para reescribir el archivo AOF a las 10 de la mañana. Más tarde, debido a que la máquina host estaba inactiva, la máquina esclava de respaldo se cambió a la máquina maestra, pero se olvidó eliminar la tarea del temporizador, lo que resultó en la trágica situación anterior. Unos días después, se descubrió el motivo.
Establezca la configuración no-appendfsync-on-rewrite en sí para aliviar este problema. Establecerlo en sí significa que la nueva operación de escritura no es fsync durante la reescritura, se almacena temporalmente en la memoria y luego se escribe una vez completada la reescritura. Es mejor no habilitar la función de respaldo AOF del Master.
Problemas de rendimiento en 4.4. Replicación maestro-esclavo de Redis.
La primera sincronización del esclavo al host se logra de la siguiente manera: el esclavo envía una solicitud de sincronización al host, el host primero descarga el archivo rdb y luego transmite el archivo rdb completo al esclavo. y luego el host El comando almacenado en caché se reenvía al esclavo y se completa la sincronización inicial. La segunda implementación de sincronización y las siguientes son: el Maestro envía instantáneas de variables directamente al Esclavo en tiempo real. Independientemente de la causa de que el esclavo y el maestro se desconectaran y reconectaran, se repite el proceso anterior. La replicación maestro-esclavo de Redis se basa en la persistencia de instantáneas de memoria. Mientras haya un esclavo, habrá una instantánea de la memoria. Aunque Redis afirma que la replicación maestro-esclavo no es bloqueante, debido a que Redis usa un servicio de un solo subproceso, si el archivo de instantánea maestra es grande, la primera transferencia completa llevará mucho tiempo y es posible que el maestro no pueda proporcionar servicios. durante el proceso de transferencia de archivos, lo que significa que el servicio se interrumpirá, lo que también es terrible para los servicios críticos.
La causa principal de lo anterior 1.2.3.4 es el cuello de botella io del sistema, es decir, el disco duro no lee y escribe lo suficientemente rápido y las operaciones fsync()/write() del proceso principal están bloqueadas. .
5. Problema de punto único de falla
La replicación maestro-esclavo actual de Redis no está lo suficientemente madura y hay puntos únicos de falla obvios. En la actualidad, este problema solo puede resolverlo uno mismo, como la replicación activa, y el agente actúa como esclavo en nombre del maestro. Esta es también una de las prioridades actuales de los autores de Redis. La solución del autor es simple pero elegante. Para obtener más información, consulte el borrador de diseño de Redis Sentinel.
Resumen
Es mejor que Master no realice ningún trabajo de persistencia, incluidas instantáneas de memoria y archivos de registro AOF, especialmente para no habilitar instantáneas de memoria para la persistencia.
Si los datos son críticos, el esclavo inicia AOF para hacer una copia de seguridad de los datos y la estrategia es sincronizarlos una vez por segundo.
Para la velocidad de replicación maestro-esclavo y la estabilidad de la conexión, el maestro y el esclavo deben estar en la misma LAN.
Intente evitar agregar bibliotecas esclavas a la biblioteca principal estresada.
Para la estabilidad del maestro, la replicación maestro-esclavo no utiliza una estructura gráfica, sino que utiliza una estructura de lista vinculada unidireccional para ser más estable, es decir, la relación maestro-esclavo es: maestro