Redis es una base de datos de memoria de código abierto que admite almacenamiento persistente y una variedad de estructuras de datos, incluidas cadenas, tablas hash, listas, conjuntos, conjuntos ordenados y más. Redis se usa ampliamente en escenarios como almacenamiento en caché, colas de mensajes, estadísticas en tiempo real, tablas de clasificación y análisis de datos en tiempo real.

Las características de Redis incluyen:

Alto rendimiento: Redis almacena datos en la memoria y la velocidad de lectura y escritura es muy rápida.
Múltiples estructuras de datos: Redis admite múltiples estructuras de datos, incluidas cadenas, tablas hash, listas, conjuntos, conjuntos ordenados, etc.
Almacenamiento persistente: Redis admite el almacenamiento persistente de datos en el disco para garantizar que los datos no se pierdan debido a la finalización del proceso.
Soporte distribuido: Redis es compatible con la arquitectura distribuida y puede realizar almacenamiento distribuido y equilibrio de carga de datos a través de varias instancias de Redis.
Buena escalabilidad: Redis admite la replicación de datos y la sincronización maestro-esclavo, lo que puede lograr una separación de lectura y escritura y una alta disponibilidad.

En resumen, Redis es una base de datos en memoria rica en funciones, de alto rendimiento y fácil de usar que se usa ampliamente en varios escenarios.

2. ¿Por qué Redis es tan rápido?

Tres razones:

1. Redis es un almacén de datos basado en RAM. El acceso a la RAM es al menos 1000 veces más rápido que el acceso aleatorio al disco.

2. Redis utiliza multiplexación de E/S y bucles de ejecución de subproceso único para mejorar la eficiencia de la ejecución.

3. Redis utiliza varias estructuras de datos subyacentes eficientes.

3. ¿Cuáles son los esquemas de selección de tecnología comunes para el almacenamiento en caché distribuido?

Excepto redis. Y Memcached es más común

Memcached es un sistema de almacenamiento en caché liviano que es fácil de usar, tiene un alto rendimiento y puede manejar un alto acceso simultáneo. Memcached no admite persistencia. Los datos generalmente se almacenan en la memoria. Cuando la memoria es insuficiente, los datos se migrarán a otros nodos de acuerdo con el algoritmo hash consistente. Memcached admite subprocesos múltiples y puede manejar varias solicitudes al mismo tiempo.

4. ¿Conoces la diferencia entre Redis y Memcached?

terreno común:

Ambos utilizan la memoria como principal medio de almacenamiento, que puede responder rápidamente a las solicitudes de lectura y escritura y mejorar la velocidad de acceso.
Ambos admiten el almacenamiento en caché distribuido, que puede distribuir datos a varios nodos y mejorar la disponibilidad y el rendimiento del sistema de almacenamiento en caché.
Ambos admiten estructuras de datos simples, como cadenas, listas, hashes, etc., que pueden satisfacer la mayoría de las necesidades de almacenamiento en caché.

Sin embargo, Redis y Memcached también tienen algunas diferencias:

Estructura de datos: Redis admite una variedad de estructuras de datos, incluidas cadenas, hashes, listas, conjuntos, conjuntos ordenados, etc. Cada estructura de datos admite diferentes operaciones y puede cumplir con requisitos de almacenamiento en caché más complejos. Memcached solo admite el almacenamiento de pares clave-valor y la operación es relativamente simple.
Persistencia: Redis admite la persistencia de datos, que puede guardar datos en el disco para evitar la pérdida de datos. Sin embargo, Memcached no admite la persistencia. Los datos generalmente se almacenan en la memoria. Cuando la memoria es insuficiente, los datos se migrarán a otros nodos de acuerdo con el algoritmo hash consistente.
Rendimiento: el rendimiento de Redis es superior al de Memcached, especialmente en términos de alta concurrencia, estructuras de datos complejas y persistencia de datos.Redis funciona mejor. Sin embargo, el consumo de recursos de Redis también es mayor.
Bloqueos distribuidos: Redis admite la implementación de bloqueos distribuidos, mientras que Memcached no admite bloqueos distribuidos de forma nativa y debe implementarse de otras maneras.

5. ¿Cuáles son los escenarios de uso de Redis?

Enumere algunos escenarios de uso comunes:

Almacenamiento en caché: el escenario de uso más común para Redis es el almacenamiento en caché. Dado que Redis utiliza la memoria como medio de almacenamiento, puede responder rápidamente a las solicitudes de lectura y escritura y mejorar la velocidad de acceso. Los datos calientes se pueden almacenar en caché en Redis para evitar el acceso frecuente a la base de datos, lo que mejora el rendimiento de la aplicación.
Cola de mensajes: el mecanismo de publicación y suscripción de Redis se puede utilizar para crear un sistema de cola de mensajes simple. Se puede publicar un mensaje en un canal en Redis, y el cliente que se suscribe al canal puede recibir el mensaje, realizando así la publicación y el consumo del mensaje.
Bloqueos distribuidos: Redis se puede utilizar para implementar bloqueos distribuidos. Dado que Redis admite operaciones atómicas, Redis se puede utilizar para implementar bloqueos distribuidos para evitar que varios procesos accedan a recursos compartidos al mismo tiempo, lo que garantiza la coherencia de los datos y la seguridad del sistema.
Contador: Redis admite operaciones atómicas y se puede usar para implementar contadores. El contador se puede almacenar en Redis y varios clientes pueden operar en el contador al mismo tiempo, realizando así la función del contador distribuido.
Aplicación de ubicación geográfica: Redis admite tipos de datos de ubicación geográfica, que se pueden usar para almacenar información de ubicación geográfica, como la latitud y la longitud, para realizar aplicaciones de ubicación geográfica.
Tabla de clasificación en tiempo real: Redis se puede usar para almacenar datos en tiempo real y ordenarlos de acuerdo con los datos, que se pueden usar para realizar la función de tabla de clasificación en tiempo real.
Gestión de sesiones: Redis se puede utilizar para almacenar datos de sesión, como información de usuario, estado de inicio de sesión, etc., para realizar la función de gestión de sesiones.

6. ¿Cuáles son las estructuras de datos más utilizadas en Redis?

Redis admite una variedad de estructuras de datos, incluidas las siguientes estructuras de datos de uso común:

String (cadena): String es una de las estructuras de datos más básicas de Redis, que puede almacenar tipos de datos como cadenas, enteros y números de coma flotante.
Hash (hash): un hash es una colección de pares clave-valor que puede almacenar múltiples campos y valores, similar a una pequeña base de datos relacional.
Lista (list): una lista es una colección ordenada de cadenas que se pueden insertar y eliminar en ambos extremos de la lista y admite varias estructuras de datos, como colas y pilas.
Conjunto (set): un conjunto es una colección desordenada de cadenas. En el conjunto se pueden realizar operaciones como agregar, eliminar, intersectar y unir, y se puede usar para la deduplicación de datos.
Conjunto ordenado (sorted set): un conjunto ordenado es un conjunto ordenado de cadenas, cada elemento tiene una puntuación, que puede realizar operaciones como la clasificación y la consulta de intervalos, y a menudo se usa para implementar funciones como tablas de clasificación y sistemas de puntuación.

Tres tipos de datos especiales son HyperLogLogs (estadísticas de cardinalidad), Bitmaps (mapa de bits) y geoespacial (ubicación geográfica)

7. ¿Cuáles son las estructuras de datos subyacentes de los tipos de datos de Redis?

Redis admite los siguientes cinco tipos de datos principales, cada uno de los cuales tiene una implementación de estructura de datos subyacente diferente:

String (cadena): La capa subyacente se implementa con Simple Dynamic String (SDS), que admite operaciones de seguridad binaria.
Hash (Hash): La capa inferior se implementa mediante una tabla hash, que admite operaciones rápidas de búsqueda, inserción y eliminación.
List (lista): la capa inferior se implementa mediante una lista doblemente enlazada, que admite operaciones rápidas de inserción y eliminación en la cabeza y la cola.
Conjunto (conjunto): la capa inferior se implementa mediante una tabla hash o una tabla de salto, que admite operaciones de conjunto eficientes, como unión, intersección y diferencia.
Conjunto ordenado (conjunto ordenado): la capa inferior se implementa mediante una combinación de tabla de salto y tabla hash, y admite operaciones de clasificación por puntuación y por miembro.

8. ¿Por qué diseñar sds?

Redis diseñó una cadena dinámica simple SDS (Simple Dynamic String), principalmente para resolver algunos problemas existentes en la matriz de caracteres tradicional (char array) en lenguaje C, como los siguientes puntos:

El espacio no es fácil de ajustar dinámicamente: la matriz de caracteres en lenguaje C debe especificar su longitud al definirla, si la longitud no es suficiente, debe redefinir una matriz más grande y luego copiar los datos de la matriz original a la nueva matriz, tal operación es muy engorrosa y propensa a errores.
No se admite la seguridad binaria: las matrices de caracteres en lenguaje C usan '\0' como terminador, por lo que no se admiten los datos binarios o las cadenas que contienen caracteres '\0'.
Problema de rendimiento: la matriz de caracteres en lenguaje C necesita atravesar toda la matriz para calcular la longitud al obtener su longitud, lo cual es ineficiente.

SDS puede resolver el problema anterior manteniendo un puntero buf apuntando a la memoria asignada dinámicamente y registrando la información de longitud de la cadena al mismo tiempo. Las ventajas son las siguientes:

1. Expansión dinámica

La estructura interna de SDS se compone de longitud, espacio disponible y matriz de caracteres. El espacio libre se refiere al espacio no utilizado en la matriz de cadenas. En comparación con el tipo de cadena nativa del lenguaje C, SDS se puede expandir dinámicamente, es decir, cuando la longitud de la cadena excede el espacio disponible, el espacio disponible aumenta automáticamente. Este diseño hace que la operación de SDS sea más eficiente, evitando la sobrecarga de reasignar memoria y copiar cadenas muchas veces.

2. Reducir el riesgo de desbordamiento del búfer

El tipo de cadena nativa del lenguaje C no limita la longitud.Si la longitud de la cadena supera la longitud de la matriz de caracteres, se producirá un problema de desbordamiento del búfer. SDS ha diseñado un atributo buf para almacenar el contenido real de la cadena. La longitud de la matriz buf se controla dentro de la longitud real de la cadena, evitando así el riesgo de desbordamiento del búfer.

3. Compatible con el tipo de cadena nativa del lenguaje C

Para ser compatible con el tipo de cadena nativa del lenguaje C, SDS reserva un carácter nulo ('\0') en la estructura interna. Esto permite que SDS se comporte como cadenas nativas cuando interactúa con otras funciones del lenguaje C.

4. Seguridad binaria

El tipo de cadena nativa del lenguaje C utiliza un carácter nulo ('\0') como final de la cadena, lo que significa que solo puede almacenar datos de texto. SDS es binario seguro y puede almacenar cualquier dato binario. Este diseño hace que SDS sea muy útil para almacenar claves y valores en Redis.

5. Optimice las operaciones con cadenas

La información de longitud de la cadena se almacena en la estructura interna de SDS, lo que hace que la operación de obtener la longitud de la cadena sea O(1) compleja en el tiempo. Además, SDS también proporciona algunas otras funciones de manipulación de cadenas, como la adición de cadenas, la copia de cadenas, etc. Estas funciones son más eficientes que las funciones de manipulación de cadenas nativas del lenguaje C.

Parte del código fuente de SDS de Redis7.0 es el siguiente (https://github.com/redis/redis/blob/7.0/src/sds.h):

/* Note: sdshdr5 is never used, we just access the flags byte directly.
 * However is here to document the layout of type 5 SDS strings. */
struct __attribute__ ((__packed__)) sdshdr5 {
    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    unsigned char flags; /* 3 lsb of type, 5 unused bits */
    char buf[];
};

Puede verse en el código fuente que hay cinco métodos de implementación de SDS: SDS_TYPE_5 (no utilizado), SDS_TYPE_8, SDS_TYPE_16, SDS_TYPE_32 y SDS_TYPE_64, de los cuales solo se utilizan los últimos cuatro. Redis decidirá qué tipo usar en función de la duración de la inicialización, lo que reduce el uso de memoria.

tipo	byte	poco
sdshdr5	< 1	<8
sdshdr8	1	8
sdshdr16	2	dieciséis
sdshdr32	4	32
sdshdr64	8	64

Para las últimas cuatro implementaciones, se incluyen los siguientes cuatro atributos:

len: La longitud de la cadena es el número de bytes ya utilizados
alloc: El tamaño de espacio de caracteres disponible total, alloc-len es el tamaño de espacio restante de SDS
buf[]: la matriz que realmente almacena la cadena
flags: Los tres bits inferiores guardan el indicador de tipo

9. Hable sobre la estructura subyacente de zset (tabla de salto)

La tabla de salto admite la búsqueda de complejidad de O(logN) promedio, peor O(N) y la implementación subyacente de zset (conjunto ordenado)

características de zset:

Una colección no repetitiva pero ordenada de elementos de cadena;
Cada elemento está asociado con una puntuación de tipo doble y Redis ordena de menor a mayor según la puntuación;
La partitura se puede repetir, y las repetidas se ordenan según el orden de inserción;

zskiplistNodeLa estructura contiene una matriz de valores de elementos, valores de puntuación, punteros de retroceso y punteros de nivel. Cada elemento de la matriz de punteros de nivel contiene el siguiente nodo del nodo actual en el nivel correspondiente y el intervalo desde el nodo actual hasta el siguiente nodo, que se utiliza para calcular la clasificación y eliminar el nodo.

En Redis, los elementos de la lista de saltos se usan para implementar una colección ordenada, y cada elemento contiene un valor y una puntuación, donde la puntuación se usa para ordenar los elementos. Por lo tanto, el punterozskiplistNode en la estructura apunta a un objeto Redis ( ), que contiene el valor del elemento y representa la puntuación del elemento.objrobjscore

Además del valor y la puntuación del elemento, zskiplistNodela estructura también contiene un puntero hacia atrás, que apunta al nodo anterior del nodo actual. El papel del puntero trasero es facilitar el recorrido inverso en la tabla de salto.

/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
	//数据
    sds ele;
    //节点分值
    double score;
    //节点的后退指针
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        //节点的前进指针
        struct zskiplistNode *forward;
        //跨度
        unsigned long span;
    } level[];
} zskiplistNode;

typedef struct zskiplist {
	//跳跃表的头结点和尾节点
    struct zskiplistNode *header, *tail;
    //跳跃表的长度
    unsigned long length;
    //跳跃表的层数
    int level;
} zskiplist;

Finalmente, la matriz de punteros de capa del nodo de la tabla de saltos es la parte central en la implementación de la tabla de saltos, que se utiliza para realizar búsquedas y borrados rápidos. La matriz de nivel de cada nodo contiene varios punteros que apuntan al siguiente nodo del nodo actual en cada nivel. La longitud de la matriz de punteros de nivel se genera de acuerdo con un algoritmo aleatorio, y el número de niveles de cada nodo es diferente, y el valor máximo es 32. Cada elemento de la matriz de punteros de jerarquía también contiene un spanatributo , que representa el intervalo desde el nodo actual hasta el siguiente nodo, y se utiliza para calcular la clasificación.

10. ¿Cuál es la capacidad máxima que Redis puede almacenar para un valor de tipo cadena?

El valor del tipo de cadena Redis puede almacenar hasta 512 MB de datos. Si necesita almacenar datos más grandes, puede dividirlos en varios bloques de menos de 512 MB y almacenarlos en varias claves de tipo cadena o usar otras estructuras de datos de Redis para almacenar datos.

11. Explicar en detalle el modelo de subproceso único de Redis

Redis es un modelo de un solo proceso y un solo subproceso. Los datos oficiales pueden llegar a más de 100 000 QPS (consultas por segundo)

¿Por qué la eficiencia es alta?

1. Operación de memoria pura

2. Basado en el mecanismo de multiplexación IO sin bloqueo

3. Evite el cambio frecuente de contexto de múltiples subprocesos

Redis desarrolló su propio procesador de eventos de archivos de procesador de eventos de red basado en el modelo Reactor, y el procesador es de subproceso único, por lo que redis está diseñado como un modelo de subproceso único.

El patrón Reactor es un patrón de diseño dirigido por eventos Su idea central es dividir el procesamiento de eventos en dos etapas: distribución de eventos y procesamiento de eventos. En la fase de distribución de eventos, el sistema monitoreará continuamente los eventos a través de un bucle de eventos (Event Loop); en la fase de procesamiento de eventos, cuando ocurra un evento, el sistema entregará el evento al controlador de eventos correspondiente para su procesamiento. Este modo puede reducir la cantidad de subprocesos en el sistema y puede mejorar la escalabilidad y el rendimiento del sistema.

En Redis, el ciclo de eventos se denomina "bucle principal", que escucha todos los eventos de la red y los eventos de archivos, y agrega estos eventos a una cola de eventos. Cuando hay un evento en la cola de eventos, Redis llamará al controlador de eventos correspondiente para su procesamiento. Durante la ejecución del procesador, Redis llama a algoritmos y estructuras de datos internos para procesar los datos de manera eficiente.

Además, Redis también usa tecnología de multiplexación para implementar el monitoreo de eventos, es decir, usar un subproceso para monitorear múltiples conexiones de red, a fin de evitar la sobrecarga del cambio de subprocesos y mejorar el rendimiento del sistema.

12. ¿Por qué se debe establecer un tiempo de caducidad para los datos almacenados en caché?

La función principal de Redis al establecer el tiempo de caducidad de los datos almacenados en caché es controlar el ciclo de vida de los datos almacenados en caché.

1. Asegúrese de que los datos en la memoria caché no existan siempre, lo que garantiza la eficacia de la memoria caché y reduce la presión de la memoria.

2. Necesidades comerciales.

Específicamente, cuando se establece un tiempo de caducidad para un par clave-valor en Redis, Redis eliminará automáticamente el par clave-valor de la memoria caché después de que llegue la hora, de modo que el espacio de la memoria caché se pueda liberar a tiempo para evitar la caducidad de la memoria caché. en el desperdicio de memoria. Al mismo tiempo, cuando un cliente solicita un par clave-valor, si Redis descubre que el par clave-valor ha caducado, devolverá un valor nulo o volverá a cargar los datos más recientes en la memoria caché.

Además, establecer el tiempo de caducidad también puede ayudar a prevenir problemas como la avería y la avalancha de caché. Cuando el caché falla, una gran cantidad de solicitudes solicitan simultáneamente un dato que no existe en el caché pero sí en la base de datos, lo que genera una presión excesiva sobre la base de datos; y la avalancha de caché se refiere a la presión sobre la base de datos causada por el vencimiento simultáneo de una gran cantidad de pares clave-valor en el caso de caché de aumento repentino. Establecer el tiempo de caducidad puede evitar estos problemas de manera efectiva.

13. ¿Cómo determina Redis si los datos han caducado?

Redis juzga si los datos han caducado mediante la eliminación diferida y la eliminación periódica.

1. Eliminación perezosa

La eliminación diferida significa que cuando un cliente de Redis solicita un par clave-valor, Redis verifica si el par clave-valor ha caducado antes de devolver los datos. Si caduca, lo elimina y devuelve un valor nulo o vuelve a cargar los datos más recientes en la memoria caché. La ventaja de este método es que puede garantizar el rendimiento en tiempo real de los datos, la desventaja es que los datos caducados solo se pueden encontrar cuando el cliente lo solicita, lo que puede generar tiempos de respuesta más largos para algunas solicitudes.

2. Eliminar periódicamente

La eliminación periódica significa que Redis inicia un temporizador en segundo plano, verifica regularmente todos los pares clave-valor con un tiempo de vencimiento establecido y elimina el par clave-valor si encuentra que un par clave-valor ha expirado. Redis guarda todos los pares clave-valor con una fecha de caducidad mediante una estructura denominada "diccionario de caducidad". La clave de este diccionario es la clave del par clave-valor y el valor es la marca de tiempo de caducidad del par clave-valor. . Cuando se ejecuta el eliminador regular, Redis recorrerá el diccionario caducado y eliminará todos los pares clave-valor caducados.

Para equilibrar las ventajas y desventajas de la eliminación perezosa y la eliminación periódica, Redis utiliza una estrategia híbrida. Cuando una clave caduca, Redis la agrega a un diccionario de caducidad y utiliza una estrategia de eliminación diferida para limpiar las claves caducadas. Además, Redis realizará periódicamente tareas de eliminación regulares para limpiar las claves caducadas que no se pueden limpiar a tiempo mediante la eliminación diferida.

Para evitar la acumulación excesiva de claves caducadas en la memoria, Redis utilizará algunos medios técnicos durante el proceso de limpieza de claves caducadas, tales como: usar tecnología de partición para dispersar las claves caducadas en diferentes áreas y limitar las claves caducadas procesadas por cada eliminación periódica Cantidad de tareas, etc.

14. Hable sobre el mecanismo de eliminación de memoria de Redis

Redis implementa varios mecanismos de eliminación de memoria. Las siguientes son varias implementaciones comunes del mecanismo de eliminación de memoria de Redis:

LRU (Usado menos recientemente) Algoritmo de uso menos reciente: Redis usa el algoritmo LRU para seleccionar las claves que se eliminarán. El algoritmo LRU priorizará la eliminación de las claves utilizadas menos recientemente, es decir, claves a las que se ha accedido en raras ocasiones o no se ha accedido recientemente.
LFU (Least Frequently Used) Algoritmo de uso menos frecuente: Redis utiliza el algoritmo LFU para seleccionar las claves que se eliminarán. El algoritmo LFU prioriza el desalojo de las claves menos utilizadas, es decir, las claves a las que rara vez se ha accedido o no se ha accedido recientemente.
Algoritmo aleatorio: Redis también puede usar un algoritmo aleatorio para seleccionar las claves que se eliminarán. El algoritmo aleatorio selecciona aleatoriamente una clave de todas las claves para ser eliminada.
Algoritmo de tiempo de caducidad TTL (Time To Live): Redis también puede eliminar claves en función de su tiempo de caducidad. Cuando Redis se queda sin memoria, prioriza la expulsión de claves caducadas.

15. ¿Cuál es el mecanismo de persistencia de Redis?

El mecanismo de persistencia de Redis se refiere a la persistencia de datos de Redis en el disco para evitar la pérdida de datos. Redis proporciona dos mecanismos de persistencia diferentes: RDB y AOF.

1. Mecanismo de persistencia RDB (Redis DataBase)

RDB es el mecanismo de persistencia predeterminado de Redis. El mecanismo RDB tomará una instantánea de los datos de Redis y la escribirá en el archivo RDB en el disco dentro de un intervalo de tiempo específico. Un archivo RDB es un archivo binario que contiene una instantánea de los datos de Redis en un momento determinado.

ventaja:

Los archivos RDB son pequeños y adecuados para realizar copias de seguridad y restaurar grandes cantidades de datos.
Dado que los archivos RDB son binarios, se pueden cargar mucho más rápido.
Cuando el conjunto de datos es grande, RDB es más rápido que AOF en la restauración de datos.

defecto:

Si Redis deja de funcionar, los datos del último archivo RDB guardado se perderán, lo que puede conducir a un cierto grado de pérdida de datos.
Dado que RDB se ejecuta periódicamente, si Redis deja de funcionar, los últimos datos persistentes son bastante diferentes de los datos antes del tiempo de inactividad, lo que puede provocar la pérdida de datos.

2. Mecanismo de persistencia AOF (Append-Only File)

El mecanismo AOF registra todos los comandos de escritura y los agrega al archivo AOF en el disco. Cuando se reinicia Redis, los datos se pueden restaurar volviendo a ejecutar todos los comandos en el archivo AOF.

ventaja:

El archivo AOF contiene todas las operaciones de escritura realizadas por el servidor Redis, por lo que se minimiza la pérdida de datos.
Los archivos AOF están en formato de texto, que es fácil de leer y depurar.
El mecanismo AOF admite múltiples métodos de sincronización, incluidos no, siempre y cada segundo, y puede elegir el método adecuado según sus necesidades.

defecto:

Los archivos AOF son más grandes que los archivos RDB y son adecuados para realizar copias de seguridad y restaurar cantidades más pequeñas de datos.
El mecanismo AOF necesita agregar continuamente comandos de escritura al archivo AOF, por lo que puede sufrir en términos de rendimiento de escritura.

En general, debe elegir el mecanismo de persistencia adecuado según la situación real. Si el conjunto de datos es pequeño, puede usar el mecanismo AOF para minimizar la pérdida de datos; si el conjunto de datos es grande, puede usar el mecanismo RDB para realizar copias de seguridad y restaurar datos a un costo reducido.

Al mismo tiempo, los mecanismos RDB y AOF también se pueden usar en combinación para aprovechar al máximo sus respectivas ventajas. Por ejemplo, puede establecer el mecanismo AOF en siempre y usar el mecanismo RDB para la copia de seguridad de datos regular. Esto no solo puede garantizar que los datos no se pierdan, sino también mejorar la velocidad de recuperación de datos cuando el conjunto de datos es grande.

16. ¿Método de disparo RDB?

Disparador manual: ejecute el comando de guardar, problema: el volumen de datos bloqueará el servidor actual hasta que termine el rdb y el entorno de producción esté deshabilitado.

Solución: use el comando bgsave (guardado en segundo plano), es decir, copia de seguridad en segundo plano. El proceso principal bifurcará un subproceso para completar el proceso RDB, y finalizará automáticamente después de la finalización (mecanismo multiproceso de copia en escritura del sistema operativo). sistema, denominado COW). Fork también bloqueará el proceso hijo, pero el tiempo es muy corto;

Disparador automático:

1. Configure redis.conf, configure las reglas de activación y ejecute automáticamente:

# 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
# save <seconds> <changes>
# 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作
save 900 1 
save 300 10 
save 60 10000
# 以上配置的含义：900秒之内至少一次写操作、300秒之内至少发生10次写操作、
# 60秒之内发生至少10000次写操作，只要满足任一条件，均会触发bgsave

2. Cuando se ejecuta el comando de apagado para apagar el servidor, si la función de persistencia AOF no está habilitada, se ejecutará un bgsave automáticamente

3. Sincronización maestro-esclavo (esclavo y maestro establecen un mecanismo de sincronización)

Una vez establecida la conexión entre la biblioteca esclava y la biblioteca maestra, la biblioteca maestra ejecutará bgsave para transferir los datos de copia de seguridad actuales a la biblioteca esclava y también almacenará en caché las operaciones de escritura que se producen durante el proceso de copia de seguridad.

17. El proceso específico de ejecución de RDB

Redis utiliza principalmente el mecanismo de vaca multiproceso (copia en escritura) del sistema operativo para implementar la persistencia de instantáneas RDB;

1. Al ejecutar bgsave, el subproceso principal primero juzgará si hay procesos secundarios que ejecutan rdb/aof tareas persistentes y regresará directamente si es así.

2. El proceso principal bifurcará un proceso secundario y el proceso principal se bloqueará temporalmente durante el proceso de bifurcación.

3. El proceso secundario generará un archivo de instantánea temporal basado en la memoria del proceso principal. Una vez completada la persistencia, se reemplazará el archivo rdb original. Dado que seguirán llegando nuevas solicitudes de escritura durante el proceso de copia de seguridad, estas escribirán Las operaciones no estarán en la memoria principal del proceso principal (es decir, la memoria que se lee en el momento de la copia de seguridad). Escribirá en un área de memoria temporal como una copia.

4. Después de que el proceso secundario complete la persistencia de RDB, notificará al proceso principal y sincronizará los datos de escritura escritos en la memoria temporal durante la copia de seguridad en la memoria principal.

18. ¿AOF es un registro previo a la escritura o un registro posterior a la escritura?

AOF es un mecanismo de registro posterior a la escritura, es decir, cuando Redis realiza una operación de escritura, primero agrega el comando al búfer AOF en la memoria, esperando que se sincronice con el disco duro. Solo cuando el comando se agregue con éxito al archivo AOF y se sincronice con el disco duro, Redis realizará la operación de escritura real. Por lo tanto, incluso si Redis falla durante la operación de escritura, los comandos que se agregaron al búfer AOF pero que no se sincronizaron con el disco duro no se perderán y los datos se pueden recuperar reproduciendo el archivo AOF.

Dado que el mecanismo de registro posterior a la escritura no necesita sincronizar inmediatamente cada operación de escritura en el disco duro, puede mejorar en gran medida el rendimiento de escritura de Redis. Cuando se utiliza el mecanismo de registro de escritura anticipada, cada operación de escritura debe esperar a sincronizarse con el disco duro antes de volver al cliente, lo que provocará un gran retraso, especialmente cuando la carga de escritura es alta. Después de adoptar el mecanismo de registro posterior a la escritura, Redis primero puede guardar la operación de escritura en el búfer de la memoria y luego escribir de forma asincrónica el contenido del búfer en el disco duro, lo que mejora en gran medida el rendimiento de escritura.

En segundo lugar, el uso del mecanismo de registro posterior a la escritura también puede mejorar la confiabilidad de Redis. Dado que el archivo AOF registra cada operación de escritura realizada por Redis, incluso si Redis falla durante la operación, los datos se pueden recuperar reproduciendo el archivo AOF. Sin embargo, si se utiliza el mecanismo de escritura antes del registro, dado que cada operación de escritura debe sincronizarse con el disco duro de inmediato, una vez que se produzca un bloqueo, se perderán los datos.

19. ¿Cómo realizar AOF?

Para implementar el mecanismo AOF (Append-Only File), debe habilitar la función AOF en el archivo de configuración de Redis y configurar los parámetros relevantes de AOF. En Redis, AOF se puede implementar a través de los siguientes pasos:

Habilite la función AOF: en el archivo de configuración de Redis redis.conf, puede habilitar la función AOF configurando el parámetro appendonly en sí. Por ejemplo:appendonly yes
Establezca la ruta y el nombre del archivo AOF: puede especificar la ruta de guardado y el nombre del archivo AOF configurando los parámetros dir y appendfilename. Por ejemplo: dir /var/lib/redisyappendfilename "appendonly.aof"
Establezca la estrategia de sincronización AOF: puede especificar la estrategia de sincronización AOF configurando el parámetro appendfsync, es decir, especificar cuándo sincronizar los datos en el búfer AOF con el archivo AOF en el disco duro. Redis proporciona las siguientes tres estrategias de sincronización:

siempre: cada operación de escritura se sincronizará inmediatamente con el archivo AOF en el disco duro para garantizar la integridad de los datos, pero el rendimiento es bajo.
cada segundo: sincroniza los datos en el búfer AOF con el archivo AOF en el disco duro cada segundo, lo que puede mejorar el rendimiento hasta cierto punto, pero puede perder 1 segundo de datos.
no: Los datos en el búfer AOF se escriben periódicamente en el archivo AOF en el disco duro. El rendimiento es el más alto, pero puede causar la pérdida de datos.

Por ejemplo:appendfsync everysec

4. Reinicie el servicio de Redis: después de modificar los parámetros relacionados con AOF en el archivo de configuración de Redis, debe reiniciar el servicio de Redis para que la configuración surta efecto.

20. ¿Qué es la reescritura de AOF?

aof Rewrite es el proceso de comprimir aof archivos, pero no se comprime en función del archivo original, sino que es similar a las instantáneas RDB, basado en COPY ON WRITE, recorriendo los datos en la memoria y almacenando los datos de estado final en forma de comandos, que es equivalente a Un dato puede corresponder a múltiples comandos después de múltiples operaciones, pero eventualmente se convertirá en un comando para representar el estado final.

Al igual que rdb, la reescritura también necesita bifurcar el proceso secundario, que se completa en el proceso secundario.Durante el proceso de reescritura, las nuevas operaciones aún se escribirán en el archivo aof original, y estas operaciones también serán recopiladas por redis. Cuando se complete la reescritura, estas operaciones también se agregarán al nuevo archivo aof.

mecanismo de disparo

Disparador manual : llame directamente al comando bgrewriteaof para realizar una operación de reescritura

Disparador automático : determine el tiempo de disparo automático de acuerdo con los parámetros auto-aof-rewrite-min-size y auto-aof-rewrite-percentage

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB（我们线上是512MB）。

auto-aof-rewrite-percentage:相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。 代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

21. Al reescribir todo el proceso del registro, ¿dónde se bloqueará el hilo principal?

Cuando Redis bifurca un proceso secundario, necesita copiar la tabla de mapeo de memoria del proceso principal, lo que bloqueará el hilo principal.
Cuando el proceso principal de Redis escribe datos bigkey, el sistema operativo creará una copia de la página para los datos y copiará los datos originales. Esta operación también bloqueará el hilo principal.
Durante el proceso de reescritura de AOF, el proceso secundario realizará la operación de reescritura de forma independiente, pero después de que el proceso secundario termine de ejecutarse, el proceso secundario enviará una señal al proceso principal para permitir que el proceso principal agregue el contenido del búfer de reescritura al AOF. archivo. Esta operación puede bloquear el hilo principal.

22. ¿Por qué AOF reescribe no reutiliza el registro AOF original?

Escribir el mismo archivo entre procesos padre e hijo causará problemas de competencia y afectará el rendimiento del proceso padre.
Si falla el proceso de reescritura de AOF, es equivalente a contaminar el archivo AOF original y no se puede utilizar para la recuperación de datos.

Resumen de las preguntas de entrevista de alta frecuencia de Redis (Parte 1)

1. ¿Qué es Redis?