Reimpreso de https://www.cnblogs.com/xichji/p/11286443.html .
En nuestro desarrollo diario utilizamos la base de datos para almacenar datos. Dado que no suele haber alta concurrencia en las tareas generales del sistema, parece que no hay problema, pero una vez que se involucra la demanda de grandes cantidades de datos, por ejemplo, algunos productos o cuando la cantidad de visitas a la página de inicio es instantánea, un sistema que usa una base de datos para guardar datos tendrá serias desventajas de rendimiento debido a las lentas velocidades de lectura / escritura del disco orientadas al disco. La llegada de miles de solicitudes requiere el sistema para completar miles de operaciones de lectura / escritura en un período de tiempo muy corto. A menudo, esto no es lo que la base de datos puede soportar, y es extremadamente fácil paralizar el sistema de la base de datos y, en última instancia, provocar un tiempo de inactividad del servicio grave Problemas de producción .
Para superar los problemas mencionados anteriormente, los proyectos suelen introducir la tecnología NoSQL, que es una base de datos basada en memoria y proporciona ciertas funciones de persistencia. La tecnología Redis es una de las tecnologías NoSQL, pero la introducción de Redis puede causar penetración de caché, avería de caché y avalanchas de caché. Este artículo analiza estos tres temas en profundidad.
- Penetración de caché: Los datos correspondientes a la clave no existen en la fuente de datos. Cada vez que no se pueda obtener una solicitud de esta clave desde la caché, la solicitud irá a la fuente de datos, lo que puede saturar la fuente de datos. Por ejemplo, utilizando una identificación de usuario inexistente para obtener información del usuario, sin importar si hay un caché o una base de datos, si un pirata informático aprovecha esta vulnerabilidad para atacar, puede abrumar la base de datos.
- Desglose de caché: los datos correspondientes a la clave existen, pero caducan en redis. En este momento, si entra una gran cantidad de solicitudes simultáneas, estas solicitudes generalmente cargarán datos de la base de datos de backend y los restablecerán a la caché cuando la caché Esta es una gran solicitud concurrente Puede abrumar la base de datos back-end instantáneamente.
- Avalancha de caché: cuando el servidor de caché se reinicia o una gran cantidad de cachés falla en un cierto período de tiempo, también ejercerá mucha presión sobre el sistema back-end (como DB) cuando falla.
Solución de penetración de caché:
Un dato que no debe existir en la caché y no se puede consultar. Debido a que la caché se escribe pasivamente cuando se pierde, y por tolerancia a fallas, si los datos no se pueden encontrar en la capa de almacenamiento, no se escribirán en la caché, lo que resultará en estos datos inexistentes. Cada solicitud debe ir a la capa de almacenamiento para consultar, perdiendo el significado de almacenamiento en caché.
Hay muchas formas de resolver eficazmente el problema de la penetración de la caché. La más común es utilizar un filtro Bloom para convertir todos los datos posibles en un mapa de bits lo suficientemente grande. Los datos que no deben existir se verán afectados por este mapa de bits. Bloquearlo, por lo tanto evitando la presión de consulta sobre el sistema de almacenamiento subyacente. Además, existe un método más simple y grosero (esto es lo que usamos). Si los datos devueltos por una consulta están vacíos (si los datos no existen o el sistema es defectuoso), aún almacenamos en caché el resultado vacío, pero su El tiempo de caducidad será corto, no más de cinco minutos.
Solución de desglose de caché:
Se puede acceder a la clave de manera extremadamente concurrente en ciertos momentos, lo que es un dato muy "caliente". En este momento, hay un problema que debe tenerse en cuenta: el problema de la "avería" de la caché.
Usar clave mutex
Una práctica común en la industria es utilizar mutex. En pocas palabras, cuando el caché no es válido (el valor juzgado está vacío), en lugar de ir a cargar db inmediatamente, primero use ciertas operaciones con el valor de retorno de la operación exitosa de la herramienta de almacenamiento en caché (como Redis SETNX o Memcache) ADD) para establecer una clave mutex.Cuando la operación regrese con éxito, realice la operación de carga de base de datos y restablezca la caché; de lo contrario, vuelva a intentar todo el método get cache.
Solución de avalancha de caché:
La diferencia con el desglose de la caché es que aquí hay muchas cachés de claves, y la primera es una clave determinada.
¡El impacto del efecto de avalancha en el sistema subyacente cuando el caché no es válido es terrible! La mayoría de los diseñadores de sistemas consideran el uso de bloqueos o colas para asegurarse de que no habrá una gran cantidad de subprocesos leyendo y escribiendo en la base de datos al mismo tiempo, a fin de evitar que una gran cantidad de solicitudes simultáneas caigan en el sistema de almacenamiento subyacente en caso de fracaso. También existe una solución sencilla para distribuir el tiempo de caducidad de la caché de vez en cuando. Por ejemplo, podemos agregar un valor aleatorio sobre la base del tiempo de caducidad original, como de 1 a 5 minutos al azar, de modo que la tasa de repetición del Se reducirá el tiempo de caducidad de cada caché Es difícil provocar un evento de falla colectiva.
Utilice bloqueos o colas, establezca indicadores de caducidad para actualizar la caché y establezca diferentes tiempos de caducidad de la caché para las claves. También existe una solución llamada "caché de segundo nivel".