Contenido de entrevistas comunes de Redis, penetración de caché, avalancha de caché, desglose de caché
1. Penetración de caché:
Naturaleza:
Consultar datos que no están en la caché y el tráfico va directamente a mysql
Son muchas las situaciones que provocan este fenómeno, que pueden ser ataques de piratas informáticos El autor se ha encontrado con algunas personas que utilizan medios técnicos para obtener la información del número de teléfono móvil registrado en el sistema.
Puede ser un error de llamada al sistema.
También puede ser un error de lógica de datos.
por ejemplo:
Para el sistema A, asumiendo 5000 solicitudes por segundo, 4000 solicitudes son ataques maliciosos emitidos por piratas informáticos.
Los 4000 ataques emitidos por piratas informáticos no se pueden encontrar en la caché, y cada vez que vas a la base de datos para verificarlos, tampoco puedes encontrarlos.
Regala una castaña. La identificación de la base de datos comienza desde 1, como resultado, la identificación de la solicitud enviada por el pirata informático es negativa. En este caso, no habrá en el caché, y cada vez que la solicitud sea "ver el caché como nada", la base de datos se consulta directamente. La penetración de la caché de este escenario de ataque malintencionado matará directamente la base de datos.
solución:
Caché de configuración de valor nulo
La solución es muy simple: cada vez que el sistema A no lo encuentra en la base de datos, escribe un valor nulo en la caché, como set -999 UNKNOWN. En este caso, la caché estará disponible la próxima vez.
1. Cuando la consulta no existe, el resultado también se guarda en la caché. Pero puede haber un problema: una gran cantidad de solicitudes sin resultados de consultas se almacenan en la caché, luego podemos configurar la clave de estas solicitudes para que sea más corta.
Filtrar solicitudes por adelantado
Use bloom filter para escribir los datos que redis ha almacenado en caché en el filtro, pero esto es adecuado para un tipo específico de caché, si una promoción en línea ha terminado;
debe prestar atención cuando el uso de redis Bloom Filter no puede eliminar datos.
2. Filtrar las solicitudes ilegales de antemano, Redis implementa el filtro Bloom, podemos usarlo para lograr este propósito. El filtro Bloom se comprende bien, puede consultar el principio y la implementación de Bloom Filter.
Verificar el valor de la clave de la caché
- Establezca ciertas especificaciones para las claves y verifíquelas. Para las claves que no se ajustan a las especificaciones, devuelva datos falsos o datos anormales directamente.
Es mejor tener ciertas especificaciones para cada clave en caché, de modo que en el programa, las solicitudes de claves que sí lo hagan. no se ajustan a parttern son obligatorios. (Pero generalmente el programa genera automáticamente la clave)
La relación entre una solicitud legítima y una solicitud filtrada por un filtro Bloom. Una solicitud legal debe pasar por el filtro Bloom, pero el filtro Bloom no puede interceptar completamente todas las solicitudes ilegales. Aplicado al caché, podemos interceptar la mayoría de las solicitudes.
Calentamiento de caché
El calentamiento de caché consiste en cargar directamente los datos de caché relacionados en el sistema de caché después de que el sistema esté en línea. ¡De esta manera, puede evitar
el problema de consultar primero la base de datos y luego almacenar en caché los datos cuando el usuario lo solicita! ¡El usuario consulta directamente los datos en caché que
se han calentado de antemano !
2. Avalancha de caché:
2.1 Razones de la avalancha de caché:
1. En condiciones de alta concurrencia, una gran cantidad de claves de caché fallan al mismo tiempo, lo que provoca que una gran cantidad de solicitudes caigan en la base de datos. Por ejemplo, hay muchas actividades en el sistema activo al mismo tiempo, pero todas las cachés activas expiran en un momento determinado.
2.redis punto único de falla de redis
3.redis no está configurado para persistencia
La avalancha de caché se caracteriza por un momento en el que el caché falla o desaparece, y una gran cantidad de solicitudes recaen en Mysql
Por lo tanto, es poco probable que ocurra una avalancha de caché para un sistema con baja concurrencia
2.2 Solución:
También tenemos dos soluciones para solucionar la avalancha de caché:
1. Al configurar el tiempo de caducidad de la clave de Redis, agregue un número aleatorio para evitarlo.
2. Implementar servicios Redis distribuidos Cuando un servidor Redis deja de funcionar, se realiza una conmutación por error.
Modo centinela de Redis, configuración persistente.
3. El límite actual de la caché ehcache local del sistema se degrada para evitar que mysql elimine la caché de primer nivel y la caché de segundo nivel
. 4. Una vez que la caché no es válida, el bloqueo se establece para agregar un bloqueo distribuido o una cola distribuida para garantizar el hilo único (proceso) escritura de la caché (por ejemplo, redis) SETNX), para evitar que una gran cantidad de solicitudes simultáneas caigan en el sistema de almacenamiento subyacente en caso de falla. En el método de bloqueo, primero obténgalo del caché nuevamente (para evitar que otro subproceso adquiera el bloqueo primero y ya lo haya escrito en el caché), y no es necesario verificar el caché de escritura de la base de datos. (Por supuesto que también es posible: en el hilo que no ha adquirido el bloqueo (tryLock), se sondeará la caché hasta que se supere el límite)
La solución de confiabilidad de redis para la avalancha de caché es la siguiente.
De antemano: Redis está altamente disponible, maestro-esclavo + centinela, clúster de redis, para evitar un bloqueo total.
En el caso: caché ehcache local + límite actual de hystrix y degradación para evitar que se elimine MySQL.
Después del evento: Redis persiste. Una vez reiniciado, los datos se cargan automáticamente desde el disco para restaurar rápidamente los datos almacenados en caché.
El usuario envía una solicitud. Después de que el sistema A recibe la solicitud, primero verificará la caché ehcache local y luego verificará redis si no se encuentra. Si ehcache y redis no están disponibles, verifique la base de datos nuevamente y escriba los resultados en la base de datos en ehcache y redis.
Para el componente de limitación de corriente, puede establecer la cantidad de solicitudes por segundo, cuántas pueden pasar el componente y las solicitudes restantes no pasadas, ¿qué debo hacer? ¡Baja de categoría! Puede devolver algunos valores predeterminados, mensajes sencillos o valores en blanco.
Beneficios: la
base de datos nunca morirá y el componente de limitación actual garantiza que solo puedan pasar cuántas solicitudes por segundo.
Siempre que la base de datos no esté muerta, es decir, para los usuarios, se pueden procesar 2/5 de las solicitudes.
Siempre que se puedan procesar 2/5 de las solicitudes, significa que su sistema no está muerto. Para los usuarios, es posible que la página no se muestre después de unos pocos clics, pero la página se puede mostrar una vez después de algunos clics más.
3. Desglose de la caché:
Llega una gran cantidad de solicitudes un segundo después de que expira la caché
La necesidad de almacenamiento en caché interno, cola y
desglose de caché es otro concepto que suena oscuro. Se refiere a la clave de que una gran cantidad de solicitudes simultáneas caducan un segundo después de que caduca la caché, esto se debe a que la caché ha caducado y todas las solicitudes se envían a la base de datos.
El método para resolver el desglose de la caché es el mismo que el método para resolver la penetración de la caché.
Cuarto, fluctuación del búfer
caché thrash
La eliminación de caché es un fenómeno en el que los cálculos en curso no logran leer los datos del sistema de caché.
La coherencia de la caché significa que en un sistema multiprocesador, varias cachés pueden compartir una copia de datos. Cuando el valor de una caché cambia, debe comunicarse con otras cachés para notificar el cambio y actualizar los datos para garantizar que todas las copias sean iguales. valor.
La dependencia del procesador se refiere al seguimiento del procesador utilizado en la última ejecución de un proceso y, en la medida de lo posible, utilizar el mismo procesador en la siguiente ejecución. De esta manera, los procesos pueden usar la misma caché tanto como sea posible para lograr un alto rendimiento, porque la invalidación de la caché hará que el procesador esté inactivo durante docenas de ciclos de reloj.
La eliminación de caché describe el problema cuando la CPU lee el sistema de caché interno.
Cuando se reemplaza la página, si la página de reemplazo es una página a la que se accederá de nuevo pronto, se producirá una nueva interrupción por falla de página poco después de que la falla de página se interrumpa nuevamente.
La eficiencia de todo el sistema cae bruscamente; este fenómeno se llama turbulencia (jitter)
La solución a la destrucción de la memoria es:
-
1- Si se debe a un error en la estrategia de reemplazo de página, puede modificar el algoritmo de reemplazo para solucionar este problema;
-
2- Si es porque se están ejecutando demasiados programas que el programa no puede cargar todas las páginas a las que se accede con frecuencia en la memoria al mismo tiempo, se debe reducir el número de multiprogramas.
-
3- De lo contrario, quedan dos métodos: 1 finalizar el proceso, 2 aumentar la capacidad de la memoria física;
Colaborador (es): Cameron McKenzie
La falla de caché es causada por una actividad continua de la computadora que no progresa debido al uso excesivo de recursos o conflictos en el sistema de almacenamiento en caché. Una señal clave de la eliminación de la memoria caché es el uso elevado de la CPU o un sistema que parece funcionar muy lentamente. En la paliza, la computadora normalmente realizará las mismas acciones una y otra vez en un intento de completar la tarea deseada. Un proceso desvía recursos de otro proceso, que a su vez debe tomar recursos de otro proceso en un círculo vicioso si los recursos totales disponibles son insuficientes. Por ejemplo, es posible que sea necesario volver a cargar completamente un búfer de búsqueda de traducción (TLB) para capturar datos en cada barrido si la CPU no puede abordar el número total de páginas involucradas. Esto significa que no hay reutilización de la caché de TLB, lo que genera ineficiencia y tiempos de carga prolongados. En este caso,
La eliminación de caché a veces puede estar relacionada con el cambio de contexto (el procedimiento para cambiar de una tarea a otra para habilitar la multitarea y evitar cualquier conflicto). La causa subyacente puede ser que los grupos de subprocesos no tengan el tamaño adecuado en los contenedores de servlets o que los algoritmos utilizados no coincidan con el tipo de datos a los que se accede. Los métodos como los protocolos de coherencia de caché que permiten que múltiples cachés compartan una copia de memoria de un elemento de datos pueden limitar la eliminación en algunos casos de uso.
Referencia: https://searchsoftwarequality.techtarget.com/definition/cache-thrash