Levanta el velo y sigue redis durante siete preguntas consecutivas

Hola Redis, tengo algunas preguntas que quiero hacerte.

¡Hola, Redis! Llevamos muchos años juntos, desde la vaga constatación de que ahora nos hemos integrado profundamente, siempre he sabido y siempre recuerdo tu bondad, puedes hacerme más preguntas para dejarme ir más profundo para llegar a conocerte.

1. ¿Cuál es el protocolo de comunicación de redis?

 

 

 

El protocolo de comunicación de redis es un protocolo de texto. Sí, el servidor y el cliente de Redis se comunican a través del protocolo RESP (REdis Serialization Protocol). Sí, el protocolo de texto desperdicia tráfico, pero sus ventajas son intuitivas, muy simples y rendimiento de análisis. Afortunadamente, no necesitamos un cliente redis especial para comunicarnos con redis solo por telnet o flujo de texto.

Formato de comando del cliente:

• Cadenas simples, comienzan con el signo más "+"
• Errores, comience con el signo menos "-"
• Entero, comenzando con ":" dos puntos
• Cadenas a granel, comienzan con el signo de dólar "$"
• Arrays de tipo Arrays, comience con un asterisco "*"

set hello abc
一个简单的文本流就可以是redis的客户端
复制代码

 

 

 

Breve resumen

Para obtener más información, consulte redis.io/topics/prot ... El documento de redis cree que la implementación simple, el análisis rápido y la comprensión intuitiva son los aspectos más importantes de la adopción del protocolo de texto RESP. Es posible que el protocolo de texto cause un cierta cantidad de desperdicio de tráfico, pero el rendimiento y la operación son rápidos y simples, y esto también es un proceso de pesaje y coordinación.

2. ¿Redis tiene transacciones ACID?

 

 

 

Para saber si redis tiene asuntos, en realidad es muy simple. Vaya al sitio web oficial de redis para verificar el documento y encontrar:

 

Redis tiene transacciones, pero de acuerdo con la definición de transacción tradicional ACID, redis tiene las características de ACID, ACID se refiere a 1. Atomicidad 2. Consistencia 3. Aislamiento 4. Durabilidad, usaremos Los comandos de transacción de redis anteriores se utilizan para verificar si redis tiene todas las características de ACID.

 

Atomicidad

La atomicidad de la transacción significa que la base de datos ejecuta múltiples operaciones en la transacción como un todo, y el servicio ejecuta todas las operaciones en la transacción o no ejecuta una operación.

Cola de transacciones

En primer lugar, después de que redis inicia el comando de transacción múltiple, redis generará una cola para esta transacción, y los comandos para cada operación se insertarán en esta cola en orden. Los comandos en esta cola no se ejecutarán inmediatamente, hasta que el ejecutivo comando confirma la transacción. Todos los comandos en la cola se ejecutarán una vez y exclusivamente.

 

 

Correspondencia ->

 

 

Como se puede ver en el ejemplo anterior, cuando se ejecuta una transacción exitosa, los comandos en la transacción se ejecutan secuencialmente y exclusivamente en la cola. Pero otra característica de la atomicidad es que todos tienen éxito o todos fallan, que es lo que llamamos reversión en la base de datos tradicional.

Cuando ejecutamos una transacción fallida:

 

 

 

Se puede encontrar que incluso si hay una falla en el medio, la operación set abc x ya se ha ejecutado y no se ha realizado ninguna reversión.En sentido estricto, redis no es atómico.

¿Por qué redis no admite la reversión?

En realidad, esto está relacionado con el posicionamiento y el diseño de redis. Primero, veamos por qué nuestro mysql puede admitir la reversión. Esto todavía está relacionado con la escritura del registro. Redis realizará el registro AOF después de completar la operación. El posicionamiento del registro AOF es solo operaciones de registro .Registro de comandos, y mysql tiene un redolog completo, y el redolog y binlog se escriben antes de que la transacción se confirme

 

 

 

Debe saber que MySQL ha gastado mucho dinero para poder revertir. Los escenarios de aplicaciones de Redis son de mayor rendimiento frente a una alta concurrencia, por lo que redis elige una forma más simple y rápida de procesar transacciones sin revertir también está en línea con la guión.

consistencia

La coherencia de la transacción significa que si la base de datos es coherente antes de que se ejecute la transacción, luego de que se ejecute la transacción, la base de datos debe ser coherente independientemente de si la transacción se realizó correctamente.

Desde la perspectiva de redis, hay dos niveles, uno es si el error de ejecución es para garantizar la coherencia y el otro es si redis tiene un mecanismo para garantizar la coherencia cuando está inactivo.

¿Se garantizan los errores de ejecución?

 

 

 

Aún así, va a ejecutar una transacción incorrecta, identificará y tratará el error durante la ejecución de la transacción, estos errores no modificarán la base de datos ni afectarán la consistencia de la transacción.

El impacto del tiempo de inactividad en la coherencia

No considere la solución redis distribuida de alta disponibilidad por el momento. Primero observe la máquina única para ver si la recuperación del tiempo de inactividad puede satisfacer las restricciones de integridad de los datos.

Independientemente de la solución de persistencia RDB o AOF, puede utilizar el archivo RDB o el archivo AOF para restaurar datos, restaurando así la base de datos a un estado coherente.

Discuta la consistencia nuevamente

El punto de vista anterior sobre el impacto de los errores de ejecución y el tiempo de inactividad en la coherencia se tomó del "Diseño e implementación de Redis" de Huang Jianhong. Al leer este capítulo, todavía hay algunas dudas. En el análisis final, redis no es una base de datos relacional. Si solo aparece la expresión ACID En otras palabras, la consistencia significa que desde el estado A al estado B a través de la transacción sin destruir varias restricciones, solo redis no se discute sobre el negocio realizado, obviamente es una consistencia satisfactoria.

Pero si agrega negocios para hablar de consistencia, por ejemplo, A transfiere dinero a B, A reduce 10 yuanes y B aumenta 10 yuanes, porque redis no tiene reversión, no tiene la atomicidad en el sentido tradicional, entonces de Redis no debe tener la consistencia tradicional.

De hecho, aquí hay solo una breve discusión sobre cómo conectar redis con el concepto tradicional de ACID. Quizás, puede ser que piense demasiado. No tiene sentido usar el ACID de la base de datos relacional tradicional para auditar redis. Redis no tiene intención de implementarlo Asuntos de ACID.

Aislamiento

El aislamiento se refiere a la ejecución concurrente de múltiples transacciones en la base de datos, cada transacción no se afectará entre sí y los resultados de la transacción ejecutada en el estado concurrente y la transacción ejecutada en serie son exactamente iguales.

Debido a que redis es una operación de un solo subproceso, tiene un mecanismo de aislamiento natural en términos de aislamiento. Cuando redis ejecuta una transacción, el servidor de redis garantiza que la transacción no se interrumpirá durante la ejecución de la transacción, por lo que la transacción de redis siempre es serial La transacción también está aislada.

Resistencia

La durabilidad de una transacción significa que cuando se ejecuta una transacción, los resultados obtenidos al ejecutar la transacción se almacenan en el almacenamiento persistente. Incluso si el servidor se detiene después de que se ejecuta la transacción, el resultado de la transacción ejecutada no se perderá.

Si redis tiene persistencia depende del modo de persistencia de redis

• Operación de memoria pura, sin persistencia, una vez que el servicio está inactivo, todos los datos se perderán
• El modo RDB depende de la estrategia RDB. Bgsave solo se ejecutará cuando se cumpla la estrategia. La ejecución asíncrona no garantiza la persistencia de redis
• En modo Aof, solo cuando appendfsync está configurado en always, el programa ejecutará el comando y lo guardará en el disco de forma sincrónica. En este modo, redis tiene persistencia

(Establezca appendfsync en always, pero la persistencia es factible en teoría, pero generalmente no de esta manera)

Breve resumen

• Redis tiene cierta atomicidad, pero no admite la reversión
• Redis no tiene el concepto de consistencia en ACID (o redis ignora esto en su diseño)
• Redis tiene aislamiento
• Redis puede garantizar la durabilidad a través de ciertas estrategias.

Redis y ACID están pensando puramente desde la perspectiva de los usuarios. El diseño de Redis tiene más que ver con la búsqueda de la simplicidad y el alto rendimiento, y no se verá limitado por el ACID tradicional.

3. ¿Cómo se implementa el reloj de bloqueo optimista de redis?

Cuando mencionamos el bloqueo optimista, pensamos en CAS (Compare And Set) La operación CAS contiene tres operandos: el valor de la ubicación de memoria (V), el valor original esperado (A) y el nuevo valor (B). Si el valor de la ubicación de la memoria coincide con el valor original esperado, el procesador actualizará automáticamente la ubicación al nuevo valor. De lo contrario, el procesador no hace nada.

Use watch en transacciones de redis. Watch observará una o más variables clave antes de que comience la transacción. Cuando se ejecuta la transacción, es decir, cuando el servidor recibe la instrucción ejecutiva para ejecutar la cola de transacciones en caché de forma secuencial, Redis verificará las variables clave ¿Ha sido modificado desde el reloj?

 

 

 

Mecanismo de bloqueo optimista de AtomicXXX de Java

En Java, a menudo usamos algunos parámetros de bloqueo optimistas, como AtomicXXX. ¿Cómo se implementan estos mecanismos? Si redis también es el mismo que el mecanismo de implementación de Java CAS. Primero, echemos un vistazo a la clase Java Atomic. Siga el código fuente , puede ver que detrás está en realidad Unsafe_CompareAndSwapObject

 

 

 

Puede ver que compareAndSwapObject es un método nativo, necesita continuar rastreando, puede descargar el código fuente o abrir hg.openjdk.java.net/jdk8u/

 

 

 

 

 

 

cmpxchg

Se puede encontrar que rastrear el cas final, "comparar y modificar", originalmente era de dos semánticas, pero al final se completó una instrucción cpu cmpxchg. Cmpxchg es un comando de instrucción de CPU en lugar de múltiples instrucciones de cpu, por lo que no será multi -threaded La programación se interrumpe, por lo que se puede garantizar que la operación de CAS sea una operación atómica. Por supuesto, el mecanismo de cmpxchg en realidad tiene el problema de ABA y múltiples reintentos, que no se discute aquí.

Mecanismo de reloj Redis

¿El reloj redis también usa cmpxchg? Hay similitudes entre los dos y hay algunas diferencias en el uso. El reloj Redis no tiene problemas de aba y no hay un mecanismo de reintento múltiple. Una de las diferencias más importantes es:

La ejecución de la transacción de redis es realmente serial . Simplemente siga el código fuente: el código fuente extraído puede ser un poco complicado, sí, simplemente puede resumir el diagrama de estructura de datos y el diagrama de flujo simple, y luego mirar el código fuente y será mucho mas claro

 

 

 

 

 

 

 

 

 

 

 

 

almacenamiento

 

 

 

redisDb almacena una estructura dcit watch_keys El valor de cada clave vigilada es una estructura de lista enlazada, que almacena un conjunto de indicadores de cliente de redis.

Proceso

 

 

 

Esta estructura de watch_keys será consultada para su juicio cada vez que watch, multi, exec, y cada vez que se toque la tecla vigilada, se marcará como CLIENT_DIRTY_CAS

Debido a que todas las transacciones en redis son en serie, suponga que tanto el cliente A como el cliente B miran la misma clave. Cuando el cliente A realiza una modificación táctil o A se ejecuta primero, el cliente A se eliminará de este watch_keys. esta lista a CLIENT_DIRTY_CAS. Cuando el siguiente cliente B comienza a ejecutarse, juzga que su estado es CLIENT_DIRTY_CAS y discardTransaction termina la transacción.

Breve resumen

La implementación de cmpxchg usa principalmente instrucciones de la CPU. Parece que dos operaciones se completan usando una instrucción de la CPU, por lo que no será interrumpida por varios subprocesos. El mecanismo de vigilancia de redis utiliza más el mecanismo de un solo subproceso de redis en sí mismo, y utiliza la estructura de datos y el proceso de serie de watch_keys para implementar el mecanismo de bloqueo optimista.

4. ¿Cómo persiste la redis?

 

 

 

Hay dos mecanismos para la persistencia de Redis. Uno es RDB, que es una instantánea. Una instantánea es una copia de seguridad completa, que serializará todos los datos de la memoria de Redis en el disco. El otro es el diario AOF. El registro AOF registra el registro de instrucciones de la modificación de la operación de datos. Puede ser análogo al binlog de mysql. La fecha AOF solo aumentará infinitamente con el tiempo.

Al restaurar redis, la instantánea de RDB se puede restaurar leyendo directamente el disco, mientras que aof necesita reproducir todas las instrucciones de funcionamiento para restaurar Este proceso puede ser muy largo.

 

 

 

RDB

Hay dos métodos para que redis genere instantáneas RDB. Uno es guardar. Dado que redis es un proceso único y un solo hilo, use guardar directamente, redis realizará una operación de E / S de archivo enorme, porque el proceso único y el hilo único inevitablemente se bloquearán en línea. business, en términos generales, save no se usa directamente, pero se usa bgsave. Se ha dicho que redis es de un solo proceso y de un solo subproceso. De hecho, no lo es. Cuando se usa bgsave, redis bifurca un proceso hijo y la persistencia de la instantánea se transfiere al proceso hijo para que la procese y el proceso padre continúa procesando las solicitudes comerciales en línea.

mecanismo de horquilla

Si desea averiguar el principio de generación de instantáneas RDB, debe averiguar el mecanismo de la bifurcación. El mecanismo de la bifurcación es un mecanismo de proceso del sistema operativo Linux. Cuando el proceso padre bifurca un proceso hijo, el proceso hijo y el proceso marido tienen una estructura de datos de memoria común El proceso hijo recién Cuando se genera, comparte el segmento de código y el segmento de datos en la memoria con el proceso padre.

 

 

Al principio, los dos procesos tienen el mismo segmento de memoria. Cuando el proceso hijo persiste los datos, no modificará los datos de la memoria actual, pero utilizará cow (copiar al escribir) para separar las páginas del segmento de datos. Cuando el proceso padre modifica un determinado segmento de datos, la página compartida se copiará y separará, y luego el proceso padre modificará el nuevo segmento de datos.

 

 

 

División

Este proceso también se ha convertido en un proceso dividido. Originalmente, los procesos padre e hijo apuntan a muchos bloques de memoria idénticos, pero si el proceso padre modifica uno de los bloques de memoria, se copiará, dividirá y luego se ejecutará en el nuevo bloque de memoria modificar.

Debido a que el proceso secundario puede arreglar la memoria cuando se bifurca, los datos en este momento no cambiarán, por lo que podemos generar la instantánea de manera segura sin preocuparnos de que el contenido de la instantánea se vea afectado por la solicitud comercial del proceso principal. , podemos imaginar que si durante el proceso bgsave, redis no tiene ninguna operación, el proceso principal no recibe ninguna solicitud comercial y no hay respaldo, como la eliminación caducada. El proceso principal y el proceso secundario utilizarán la misma memoria bloquear.

AOF

AOF es el almacenamiento de registros de las instrucciones de operación de redis, similar al binlog para mysql. Suponiendo que AOF se ha ejecutado desde que se creó redis, entonces AOF registra los registros de todas las instrucciones de redis. Si desea restaurar redis, puede reordenar AOF. Se puede reparar toda la instancia de redis, pero el registro de AOF también tiene dos problemas relativamente grandes. Uno es que el registro de AOF aumentará con el tiempo. Si se ejecuta una gran cantidad de datos durante mucho tiempo, el volumen de registro de AOF se volverá extremadamente grande Otro problema es que cuando AOF está recuperando datos, el tiempo de recuperación será muy largo debido a la gran cantidad de reproducción.

La operación de escritura de AOF es que después de que redis haya procesado la lógica empresarial, algunos registros de AOF se guardarán de acuerdo con una estrategia determinada. Esto es muy diferente del redolog y binlog de mysql. De hecho, por esta razón, redis se debe a que la lógica de procesamiento es lo primero Después de grabar el registro de operaciones, también es una razón por la que redis no se puede deshacer.

bgrewriteaof

En respuesta a los problemas anteriores, redis también usó bgrewriteaof para reducir el registro AOF después de 2.4 El comando bgrewriteaof se usa para realizar una operación de reescritura de archivos AOF de forma asíncrona. La reescritura creará una versión optimizada del archivo AOF actual.

Modelo de combinación y combinación de RDB y AOF

Al restaurar redis, si usamos el método RDB, debido a la estrategia bgsave, podemos perder muchos datos. Si adoptamos el modelo AOF y nos recuperamos mediante la reproducción del registro de operaciones de AOF, la reproducción de registros AOF llevará mucho más tiempo que RDB.

 

 

 

Después de redis4.0, para resolver este problema, se introdujo un nuevo modo de persistencia, persistencia híbrida, que combina archivos rdb y archivos AOF parcialmente incrementales. Rdb puede usar una estrategia de almacenamiento a más largo plazo, y aof no requiere Es un cantidad total de registros, y solo necesita guardar el aof incremental desde el comienzo del almacenamiento RDB anterior hasta el período de tiempo.En términos generales, la cantidad de este registro es muy pequeña.

5. ¿Cómo redis aumenta los ingresos y reduce el gasto en el uso de memoria?

 

 

 

Redis es diferente de otras bases de datos tradicionales. Redis es una base de datos de memoria pura y almacena datos con algunas estructuras de datos. Si la memoria no está controlada, es probable que redis haga que el sistema se bloquee debido a un volumen excesivo de datos.

ziplist

127.0.0.1:6379> hset hash_test abc 1
(integer) 1
127.0.0.1:6379> object encoding hash_test
"ziplist"
127.0.0.1:6379> zadd z_test 10 key
(integer) 1
127.0.0.1:6379> object encoding z_test
"ziplist"

Cuando intenté por primera vez abrir una pequeña estructura hash de datos y una estructura zset, descubrí que su tipo de estructura real en redis es una lista zip. La lista zip es una estructura de datos compacta. Cada elemento es una memoria continua. Si la estructura de datos habilitada por redis es muy pequeño en redis, redis cambiará al uso de almacenamiento compacto para almacenamiento comprimido.

 

 

 

Por ejemplo, en el ejemplo anterior, usamos una estructura hash para el almacenamiento. La estructura hash es una estructura bidimensional, que es una estructura típica en la que se intercambia espacio por tiempo. Sin embargo, si la cantidad de datos utilizada es muy pequeña, el uso de una estructura bidimensional desperdiciará espacio y el rendimiento del tiempo no ha mejorado mucho. Es mejor usar una estructura unidimensional para el almacenamiento. Al mirar arriba, aunque la complejidad es O (n), pero debido a que la cantidad de datos es pequeña, también es muy rápido de recorrer, y es más rápido que la consulta de la estructura hash en sí.

Si los elementos del objeto de colección continúan aumentando, o el valor de un determinado valor es demasiado grande, este almacenamiento de objetos pequeños también se actualizará para generar una estructura estándar. Redis también puede definir los parámetros de conversión de estructura compacta y estructura estándar en la configuración:

hash-max-ziplist-entries 512  # hash的元素个数超过512就必须用标准结构存储
hash-max-ziplist-value 64     # hash的任意元素的key/value的长度超过 64 就必须用标准结构存储
list-max-ziplist-entries 512  
list-max-ziplist-value 64  
zset-max-ziplist-entries 128 
zset-max-ziplist-value 64  
set-max-intset-entries 512 

lista rápida

127.0.0.1:6379> rpush key v1
(integer) 1
127.0.0.1:6379> object encoding key
"quicklist"

La estructura de datos de lista rápida es una estructura de datos de lista doblemente enlazada introducida por redis en 3.2, y de hecho es una lista de ziplist doblemente enlazada. Cada nodo de datos de la lista rápida es una lista zip, y la lista zip en sí es una lista compacta. Si la lista rápida contiene 5 nodos ziplist, y cada lista ziplist contiene 5 datos, entonces, desde el exterior, esta lista rápida contiene 25 elementos de datos.

 

 

 

La estructura de la lista rápida se resume simplemente como un compromiso entre el espacio y el tiempo:

• Una lista doblemente vinculada puede realizar operaciones push y pop en ambos extremos, pero además de guardar sus propios datos en cada nodo, también guarda dos punteros, lo que agrega una sobrecarga de memoria adicional. En segundo lugar, debido a que cada nodo es independiente, la dirección de la memoria no es continua y más nodos son propensos a la fragmentación de la memoria.
• La lista zip en sí es una memoria contigua, que tiene una alta eficiencia de almacenamiento y consulta. Sin embargo, no es propicia para operaciones de modificación. Cada vez que los datos cambian, activará una reasignación de memoria. Si la longitud de la lista zip es muy larga, un realloc provocará una gran cantidad de copias de datos.

Por lo tanto, combinando las ventajas de ziplist y lista doblemente enlazada, nació quciklist.

Compartir objetos

Redis ha construido un método de recuento de referencias en su propio sistema de objetos, a través del cual se puede rastrear la información de recuento de referencia del objeto. Además de liberar el objeto en el momento adecuado, también se puede utilizar como un objeto para compartir. Por ejemplo, si la clave A crea una cadena con un valor entero de 100 como objeto de valor, en este momento la clave B también crea un objeto de cadena con el mismo valor entero de 100 como objeto de valor, luego durante la operación redis:

• Hablando del puntero clave de la base de datos, apunta a un objeto de valor existente
• Hable sobre el recuento de referencias de objetos de valor compartido más uno

 

 

 

Si hay cientos de claves que apuntan al valor entero 100 en nuestra base de datos, no solo hay claves A y B, sino algunos cientos, entonces el servidor de redis solo necesita la memoria de un objeto de cadena para guardar los cientos originales de objetos de cadena. .Datos que solo se pueden almacenar en la memoria.

6. ¿Cómo logra redis la replicación maestro-esclavo?

 

 

 

Varias definiciones

• runID ID del servidor en ejecución
• offset El offset de replicación del servidor maestro y el offset de la replicación del servidor
• atrasos de replicación El búfer de trabajos atrasados ​​de replicación del servidor primario

Después de redis2.8, use el comando psync en lugar del comando sync para realizar la operación de sincronización de la replicación. El comando psync tiene dos modos de resincronización completa y resincronización parcial:

• La sincronización completa se utiliza para manejar la situación de replicación inicial: los pasos de ejecución de la resincronización completa son los mismos que los pasos de ejecución del comando sync. Ambos se sincronizan permitiendo que el servidor maestro cree y envíe el archivo rdb y envíe la escritura comando guardado en el búfer al servidor esclavo.
• La resincronización parcial se utiliza para manejar la re-replicación después de la desconexión: cuando el servidor esclavo se vuelve a conectar al servidor maestro después de la desconexión, el servicio maestro puede enviar el comando de escritura ejecutado durante la desconexión del servidor maestro al servidor esclavo y al servidor esclavo solo necesita Después de recibir y ejecutar estos comandos de escritura, la base de datos se puede actualizar al estado actual del servidor principal.

Resincronización completa:

 

 

1. El esclavo envía psync al maestro, porque es la primera vez que lo envía, sin runid y offset
2. El maestro recibe la solicitud y envía el runid y el desplazamiento del maestro al nodo esclavo
3. master genera y guarda el archivo rdb
4. El maestro envía el archivo rdb al esclavo
5. Mientras se envía la operación RDB, la operación de escritura se copiará en el búfer de acumulación de replicación del búfer y se enviará desde el área del búfer al esclavo
6. El esclavo carga los datos del archivo rdb y actualiza sus propios datos

Si la red está nerviosa o la desconexión a corto plazo también requiere una sincronización completa, causará muchos gastos generales. Estos gastos generales incluyen el tiempo de bgsave, el tiempo de transferencia de archivos RDB, el tiempo de recarga del esclavo RDB, si el esclavo ha aof, también conducirá a aof reescribir. Estos son muchos gastos generales, por lo que también se implementa un mecanismo de resincronización parcial después de redis2.8.

Resincronización parcial:

 

 

 

1. Se produjo un error en la red y el maestro y el esclavo perdieron la conexión
2. El maestro todavía escribe datos en el búfer búfer
3. El esclavo se vuelve a conectar con el maestro
4. El esclavo envía su runid actual y su compensación al maestro
5. El maestro determinará si el desplazamiento enviado por el esclavo a sí mismo está en la cola del búfer, si existe, enviará continuar al esclavo, si no existe, significa que demasiados datos pueden estar equivocados, el búfer tiene se ha vaciado, y debe repetirse en este momento Copia completa
6. El maestro envía el desplazamiento de datos del búfer desde el desplazamiento al esclavo
7. El esclavo obtiene datos para actualizar sus propios datos

7. ¿Cómo formula redis una estrategia de eliminación vencida?

Cuando una clave está en un estado caducado, de hecho, la memoria en redis no se elimina de la memoria en tiempo real, pero redis utiliza un cierto mecanismo para eliminar algunas claves caducadas y luego libera la memoria. Cuando una clave caduca, ¿Cuándo lo eliminará redis? Hay tres posibilidades cuando se elimina, y estas tres posibilidades también representan las tres estrategias de eliminación diferentes de redis.

• Eliminación programada: mientras configura el tiempo transcurrido de la clave, cree un temporizador para que la clave se elimine inmediatamente cuando expire.
• Eliminación diferida: deje que la clave caduque independientemente, pero cada vez que la clave se obtenga del espacio de claves, comprobará si la clave ha caducado y, si caduca, eliminará la clave.
• Eliminación periódica: De vez en cuando, el programa verificará la base de datos y eliminará las claves caducadas en ella. En cuanto a la cantidad de claves caducadas a eliminar, depende del algoritmo.

Eliminación programada

Establezca el tiempo de vencimiento de la clave y cree un temporizador. Una vez que llegue el momento de vencimiento, opere inmediatamente la clave. Esto es fácil de usar, pero el tiempo de la CPU es el más hostil, especialmente cuando la empresa está ocupada y las claves vencidas. , la operación de eliminar las claves caducadas ocupará una gran parte del tiempo de la CPU. Debe saber que redis es una operación de un solo subproceso. Cuando la memoria no está apretada y la CPU está apretada, el tiempo de la CPU se pierde al eliminar las caducadas claves que no tienen nada que ver con el negocio. Lo anterior afectará el tiempo de respuesta y el rendimiento del servidor de redis. Además, la creación de un temporizador necesita usar el evento de tiempo en el servidor de redis, y la implementación del evento de tiempo es una lista enlazada desordenada, y la complejidad de tiempo es O (n). Deje que el servidor cree una gran cantidad de temporizadores para implementar la estrategia de eliminación de tiempo. Tendrá un mayor impacto en el rendimiento, por lo que la eliminación regular no es una buena estrategia de eliminación.

Eliminación perezosa

A diferencia de la eliminación temporal, la estrategia de eliminación diferida es la más amigable para la CPU. El programa solo verificará cuando se recupere la clave, que es un proceso pasivo. Al mismo tiempo, la eliminación diferida es la menos amigable para la memoria. Si una clave caduca, mientras ya no se extraiga, la clave caducada no se eliminará y la memoria que ocupa no se liberará. Obviamente, la eliminación diferida no es una buena estrategia. Redis depende mucho de la memoria y de la buena memoria. Si no se accede a algunas claves de largo plazo durante mucho tiempo, se producirá mucha basura de memoria e incluso se convertirá en una pérdida de memoria.

Al escribir los datos de ejecución, la clave escrita caduca a través de la función expireIfNeeded. Entre ellas, expireIfNeeded hace tres cosas internamente, a saber:

• Compruebe si la clave ha caducado
• Propagar la acción de ejecutar la clave pasada al nodo esclavo
• Eliminar clave caducada

 

 

Eliminar regularmente

Las dos estrategias de eliminación anteriores, ya sea una eliminación programada o una eliminación diferida, tienen defectos obvios en un solo uso, ya que ocupan demasiado tiempo de CPU o desperdician demasiada memoria. La estrategia de eliminación periódica es una integración y un compromiso de las dos primeras estrategias

• La estrategia de eliminación regular ejecuta la operación de eliminación de la clave caducada de vez en cuando y reduce el impacto de la operación de eliminación en el tiempo de la CPU al limitar el tiempo y la frecuencia de la operación de eliminación.
• Se puede lograr una clave de caducidad de eliminación razonable mediante un tiempo y una frecuencia de ejecución de eliminación razonables

para resumir

Se puede decir que redis se puede describir como amplio y profundo, simple de siete preguntas o simplemente personas ciegas que tocan al elefante, o esta vez simplemente tocaron la trompa de un elefante, o deberían tocar la nariz, la próxima vez que toquen un elefante. oído, siempre y cuando esté dispuesto a profundizar Comprensión y exploración en profundidad, en lugar de solo aplicar y no pensar, un día descubrirá al elefante como redis.

[Nota: algunos capítulos se refieren y citan a Huang Jianhong "Diseño e implementación de Redis"]

Autor: Chen Yu Zhe
Enlace: https: //juejin.im/post/5d29ac845188252cc75e2d5c
Fuente: Nuggets
copyright reservado por los autores. Para reimpresiones comerciales, comuníquese con el autor para obtener autorización. Para reimpresiones no comerciales, indique la fuente.