Avalancha de caché
Supongamos que un sistema tiene 7000 solicitudes por segundo durante el período pico. En este momento, usamos la caché para resistir solicitudes tan altas. Sin embargo, si una gran cantidad de cachés falla en un momento determinado, o el servidor de caché deja de funcionar, estas solicitudes actuarán directamente sobre bases de datos ordinarias (como MySQL). Con un volumen tan alto de solicitudes, MySQL definitivamente no podrá soportarlo, y luego se bloqueará. Si la base de datos se bloquea, también hará que el sistema se bloquee.
Resumimos las condiciones para el desencadenante de avalancha de caché:
""
Alta concurrencia
El servidor de caché está inactivo
Invalidación centralizada de una gran cantidad de cachés
La consecuencia es: el sistema se bloquea.
La solución es aumentar el acceso de cola de límite actual a la base de datos. Suponiendo que nuestra base de datos puede soportar como máximo 2000 solicitudes por segundo, cuando solicitamos la base de datos, las solicitudes por segundo deben controlarse dentro de 2000, y el resto de las solicitudes deben para estar en cola. Al mismo tiempo, necesitamos utilizar un clúster para garantizar la alta disponibilidad del servidor de caché. Además, también necesitamos establecer aleatoriamente el tiempo de caducidad de la clave de caché para evitar que la clave caduque al mismo tiempo.
Resolución de avalanchas
Con respecto a las operaciones de limitación de corriente, puede usar los complementos de limitación de corriente relacionados con Spring Cloud. Aquí usamos semáforos Semaphore para simular operaciones de limitación de corriente más bajas.
Aquí limitamos que puede haber hasta 5 solicitudes para visitar al mismo tiempo. Cuando tenemos 9 solicitudes entrando, solo 5 solicitudes obtienen tokens de acceso y las 4 solicitudes restantes están esperando afuera. Al final del acceso anterior, los tokens se liberarán y las próximas 4 solicitudes se adelantarán a estos tokens, que se ejecutarán repetidamente.
Aquí hemos jugado una operación de limitación de corriente.
Penetración de caché
Suponiendo que hay una clave que nunca existirá en la caché, cuando un pirata informático usa esta clave para atacar el sistema, como por ejemplo, 7000 ataques por segundo, la caché no se utilizará de todos modos. La solicitud de ataque se golpea directamente en la base de datos y la base de datos debe ser No se puede contener. Causó la falla de la base de datos, al mismo tiempo, el sistema también se bloqueará.
penetrar
Nuestra solución es determinar si los datos de destino existen antes de realizar la consulta e ignorar los que no existen. Intercepte el tráfico antes de la caché y la base de datos.
Solución penetrante
Como se muestra en la figura anterior, agregue un filtro. Antes de que se inicie el sistema, debemos cargar los datos del hotspot en la caché. Al acceder a los datos del hotspot, el filtro los evaluará una vez. Si la solicitud no existe en el caché, volverá directamente., No pasará por la base de datos.
Filtros Podemos usar filtros de floración, el código de muestra de los filtros de floración es el siguiente:
El filtro Bloom dispersa principalmente el valor calculado por la clave a través del algoritmo hash en el mapa de bits, que existe como 0 y 1 en el mapa de bits.
mapa de bits
Sin embargo, el algoritmo anterior tiene fallas:
"Los filtros Bloom no pueden filtrar con precisión. (El filtro Bloom juzga que no existe, el 100% no existe y, si se considera que existe, es posible que no exista). En teoría, el valor de cálculo de hash choca (diferentes hashes de contenido calculan el mismo valor), que da como resultado la inexistencia Se puede juzgar que los elementos existen
"
Por supuesto, el filtro Bloom no necesita interceptar todas las solicitudes, solo necesita controlar el desglose de la caché en una cierta cantidad.
En cuanto a la penetración de caché, también podemos utilizar las siguientes soluciones:
"Los datos que no se pueden recuperar en la caché no se recuperan en la base de datos. En este momento, el par clave-valor también se puede escribir como clave-nula, y el tiempo efectivo de la caché se puede establecer en un tiempo corto, como como 30 segundos. No se puede utilizar). Esto puede evitar que el usuario atacante utilice repetidamente el mismo ataque de fuerza bruta de identificación.
"
Sin embargo, el esquema anterior tiene un defecto: el pirata informático puede acceder simultáneamente a múltiples claves inexistentes durante un corto tiempo y también acceder a la base de datos, por lo que en la práctica, debe optimizarse y modificarse de acuerdo con la escena.
La avalancha de caché y la penetración de caché se encuentran generalmente en situaciones de alta concurrencia. También son el contenido de entrevistas de alta frecuencia con empresas de Internet. Al dominar este conocimiento, creo que ha entrado en un mundo nuevo.
Recomendado en el pasado
-
¿Tiene miedo de las pérdidas de memoria cuando usa ThreadLocal?
-
Resumen de la entrevista de back-end de Java de 30.000 palabras (con PDF)
Escanee el código QR para ser más emocionante. O busque Lvshen_9 en WeChat , puede responder para obtener información en segundo plano
回复"java" 获取java电子书；
回复"python"获取python电子书；
回复"算法"获取算法电子书；
回复"大数据"获取大数据电子书；
回复"spring"获取SpringBoot的学习视频。
回复"面试"获取一线大厂面试资料
回复"进阶之路"获取Java进阶之路的思维导图
回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
回复"总结"获取Java后端面试经验总结PDF版
回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
回复"并发导图"获取Java并发编程思维导图（xmind终极版）Otro: haga clic en [ Mis beneficios ] para tener más sorpresas.