Penetración de caché, avalancha, avería en Redis

Descripción general:

Penetración de caché: una gran cantidad de solicitudes de claves que no existen aumentarán la presión sobre el servidor de aplicaciones
Avalancha de caché: una gran cantidad de claves en redis caducan colectivamente, aumenta la presión sobre la base de datos y el servidor falla
Desglose de caché: una clave de zona activa en redis caduca (una gran cantidad de usuarios accede a la clave de zona activa, pero la clave de zona activa caduca), y la presión de acceso de la base de datos aumenta instantáneamente

La causa raíz de la aparición de los tres: la tasa de aciertos de Redis cae y la solicitud se acierta directamente en la base de datos.

En circunstancias normales, redis responderá a una gran cantidad de solicitudes de recursos, y solo una pequeña parte de las solicitudes que no obtienen una respuesta de redis solicitarán DB, por lo que la presión sobre DB es muy pequeña y puede funcionar normalmente.

solución:

1. Penetración de caché

Los datos correspondientes a la clave no existen en redis . Cada vez que no se obtiene una solicitud de esta clave desde el caché, la solicitud se reenvía a la base de datos. Si el número de visitas es grande, la base de datos puede verse desbordada. Por ejemplo, si utiliza una identificación de usuario inexistente para obtener información del usuario, ni el caché redis ni la base de datos, si un pirata informático aprovecha esta vulnerabilidad para atacar, la base de datos puede verse abrumada (el pirata informático accede a datos que no existen, lo que causará mucha presión en el servidor).

solución:

Un dato que no debe existir, porque la memoria caché se escribe pasivamente cuando falta, y para la tolerancia a fallas, si los datos no se pueden encontrar desde la capa de almacenamiento, no se escribirán en la memoria caché, lo que provocará que estos datos no existan. se solicitará cada vez que la consulta en la capa de almacenamiento pierda el significado de almacenamiento en caché

Caché de valores vacíos: si los datos devueltos por una consulta están vacíos (ya sea que los datos no existan o no), guardamos en caché el resultado vacío (nulo), lo que puede aliviar la presión sobre el acceso a la base de datos, y luego establecemos el tiempo de caducidad de el resultado vacío sea Muy corto, no más de cinco minutos. (solo como una simple solución de emergencia)
Establecer una lista accesible (lista blanca): use el tipo de mapa de bits para definir una lista accesible. La identificación de la lista se usa como el desplazamiento de los mapas de bits. Cada visita se compara con la identificación en el mapa de bits. Si la identificación de acceso no está en el bitmaps, interceptarlo Acceso no permitido.
Filtro Bloom: haga un hash de todos los datos posibles en mapas de bits lo suficientemente grandes, y estos mapas de bits interceptarán los datos que no deben existir, evitando así la presión de consulta en el sistema de almacenamiento subyacente
Verificación de datos: similar a la intercepción de permisos de usuario, el acceso no válido de id=-3872 se intercepta directamente y estas solicitudes no pueden llegar a Redis y DB.
Monitoreo en tiempo real : cuando se descubre que la tasa de aciertos de Redis comienza a disminuir rápidamente, es necesario verificar los objetos a los que se accede y los datos a los que se accede, y cooperar con el personal de operación y mantenimiento para establecer una lista negra para restringir los servicios.

Precauciones:

Cuando se usa un valor nulo como caché, el tiempo de caducidad establecido por la clave no debe ser demasiado largo para evitar consumir demasiados recursos de Redis.
El almacenamiento en caché de valores nulos es un método de defensa pasiva. Cuando un pirata informático solicita violentamente una gran cantidad de datos que no existen, se debe escribir una gran cantidad de valores nulos en Redis, lo que puede conducir a un uso insuficiente de la memoria de Redis.
Con el filtro Bloom, puede determinar si el recurso existe cuando el usuario accede a él y, si no existe, se deniega el acceso directamente.
El filtro Bloom tiene ciertos errores, por lo que generalmente necesita cooperar con algunas restricciones de tráfico de la interfaz (regular la frecuencia de acceso de los usuarios dentro de un período de tiempo), verificación de permisos, lista negra, etc. para resolver el problema de penetración de caché.

2. Avalancha de caché

Los datos correspondientes a una gran cantidad de claves existen, pero caducan en redis Si hay una gran cantidad de solicitudes simultáneas en este momento, estas solicitudes generalmente cargarán datos de la base de datos backend y la volverán a colocar en el caché cuando encuentren que el caché expira En este momento, una gran cantidad de solicitudes simultáneas pueden abrumar instantáneamente la base de datos de back-end. La avalancha de caché está dirigida a muchas fallas clave, lo que hace que Redis no funcione y la presión de la base de datos aumente; la falla del caché significa que cierta clave popular falla, lo que hace que Redis no funcione y la presión de la base de datos aumenta.

solución:

Cree una arquitectura de caché de varios niveles: caché nginx + caché redis + otros cachés (ehcache, etc.), el diseño del programa es más complicado
Use bloqueos o colas: use bloqueos o colas para asegurarse de que no haya una gran cantidad de subprocesos leyendo y escribiendo en la base de datos al mismo tiempo, para evitar que una gran cantidad de solicitudes simultáneas caigan en el sistema de almacenamiento subyacente cuando ocurre una falla. . Baja eficiencia, no apto para situaciones de alta concurrencia
Establezca el indicador de caducidad para actualizar la memoria caché: registre si los datos de la memoria caché están vencidos (establezca la cantidad de anticipo), si caduca, se activará para notificar a otro hilo para actualizar la memoria caché de clave real en segundo plano.
Establezca el indicador de caché: registre si los datos almacenados en caché han caducado, si caduca, se activará para notificar a otro hilo para actualizar la clave real en segundo plano
Distribuya el tiempo de caducidad: mediante el uso de la generación automática de números aleatorios, el tiempo de caducidad de la clave se aleatoriza para evitar el vencimiento colectivo

3. Desglose de caché:

El motivo de la avalancha de caché: una tecla de acceso rápido en redis caduca, pero en este momento hay una gran cantidad de usuarios que acceden a la clave caducada

Redis se ejecuta normalmente y no hay una gran cantidad de caducidad (no se puede acceder después de la caducidad, si no se golpea, necesita acceder a la base de datos)
La presión de acceso a la base de datos aumenta instantáneamente

solución:

Configure los datos activos por adelantado: antes del acceso máximo a redis, almacene algunos datos activos en redis por adelantado y aumente la duración de estas teclas de datos activos
Supervise los datos y realice ajustes oportunos : controle qué datos son populares en el sitio y ajuste el tiempo de caducidad de la clave en tiempo real
Mecanismo de bloqueo: solo una solicitud puede obtener una exclusión mutua y luego consultar los datos en la base de datos y devolverlos a Redis, y luego todas las solicitudes pueden obtener respuestas de Redis