Tabla de contenido
En respuesta a la falla y el tiempo de inactividad de Redis
Caducidad de una gran cantidad de claves al mismo tiempo.
¿Cómo garantizan las bases de datos y los cachés la coherencia?
¿Debo actualizar primero el caché o la base de datos?
Problemas de coherencia de datos causados por circunstancias anormales
1. Primero actualice la base de datos y luego actualice el caché.
2. Primero actualice el caché y luego actualice la base de datos.
Problemas de coherencia causados por la concurrencia
1. Primero actualice la base de datos y luego actualice el caché.
2. Primero actualice el caché y luego actualice la base de datos.
Problemas de coherencia causados por la concurrencia
1. Primero elimine el caché y luego actualice la base de datos.
2. Primero actualice la base de datos y luego elimine el caché.
¿Cómo asegurar el éxito en ambos pasos?
2. Suscríbase al registro de cambios de la base de datos:
¿Qué son el calentamiento de caché, la avalancha de caché, el desglose de caché y la penetración de caché?
Calentamiento de caché
El precalentamiento de la caché significa que una vez que el sistema se conecta, los datos de la caché relevantes se cargan directamente en el sistema de caché por adelantado. ¡Evite el problema de consultar primero la base de datos y luego almacenar en caché los datos cuando el usuario lo solicite! ¡Los usuarios consultan directamente los datos almacenados en caché que han sido precalentados!
avalancha de caché
Cuando una gran cantidad de claves caducan al mismo tiempo o Redis falla , si hay una gran cantidad de solicitudes de usuarios, no se pueden procesar en Redis, por lo que todas las solicitudes acceden directamente a la base de datos, lo que genera un aumento repentino en la presión de la base de datos, que puede provocar gravemente un tiempo de inactividad de la base de datos, formando así Una serie de reacciones en cadena que provocan el colapso de toda la base de datos, lo que constituye una avalancha de caché.
solución
En respuesta a la falla y el tiempo de inactividad de Redis
1. Utilice el clúster de Redis para evitar problemas en una sola máquina que puedan provocar que todo el servicio de caché no esté disponible.
2. Disyuntor de servicio o mecanismo de limitación de corriente de solicitud : cuando el problema de la avalancha de caché es causado por el tiempo de inactividad de Redis, se puede activar el mecanismo de disyuntor de servicio para suspender el acceso de la aplicación empresarial al servicio de caché, devolver directamente un error y ya no acceder. base de datos, reduciendo así el impacto en la presión de la base de datos de caché, garantice el funcionamiento normal del sistema de base de datos y luego espere hasta que Redis vuelva a la normalidad antes de permitir que las aplicaciones comerciales accedan al servicio de caché.
El mecanismo de disyuntor de servicio es un permiso normal para proteger la base de datos, pero cuando las aplicaciones comerciales acceden al sistema del servidor de caché, todos los servicios no pueden funcionar normalmente. Para reducir el impacto en el negocio, podemos habilitar el mecanismo de limitación de corriente de solicitud y solo Envíe una pequeña cantidad de solicitudes a la base de datos. Para el procesamiento, no importa cuántas solicitudes haya, el servicio se negará directamente en la entrada. Después de que Redis vuelva a la normalidad y el caché se caliente, el mecanismo de limitación de corriente de solicitud será liberado.
Caducidad de una gran cantidad de claves al mismo tiempo.
1. Tiempo de vencimiento de clave uniforme para evitar que una gran cantidad de claves caduquen al mismo tiempo.
2. Bloqueo mutex : cuando el hilo procesa la solicitud comercial, si se descubre que los datos a los que se accede no están en la base de datos de Redis, agregue un bloqueo mutex para garantizar que solo una solicitud lea datos de la base de datos al mismo tiempo y luego actualiza el caché a Redis. (Al configurar un bloqueo mutex, es mejor establecer un tiempo de espera para evitar que después de que una solicitud obtenga el bloqueo, la solicitud se bloquee debido a alguna situación y no pueda liberar el bloqueo, lo que provocará que otras solicitudes no obtengan el bloqueo y el sistema dejar de responder).
3. Caché de actualización en segundo plano : el subproceso empresarial ya no es responsable de actualizar el caché y el caché no establece un período de validez, sino que el caché se vuelve "válido permanentemente" y el trabajo de actualización del caché se entrega al Hilo en segundo plano para actualizaciones periódicas.
Desglose de caché
Si ciertos datos del punto de acceso en el caché caducan y una gran cantidad de solicitudes acceden a los datos del punto de acceso, no se leerán del caché y no accederán directamente a la base de datos. La base de datos se verá fácilmente abrumada por un gran número de solicitudes simultáneas. Esto es un desglose del caché.
solución
1. El esquema de bloqueo mutex garantiza que solo un subproceso comercial actualice el caché al mismo tiempo. Si no hay una solicitud para obtener el bloqueo mutex, esperará a que se libere el bloqueo y volverá a leer el caché, o Devuelve un valor nulo o un valor predeterminado.
2. No establezca un tiempo de vencimiento para los datos del punto de acceso, no actualice el caché de forma asincrónica en segundo plano ni notifique al hilo en segundo plano con anticipación para actualizar el caché y restablecer el tiempo de vencimiento antes de que los datos del punto de acceso estén listos para caducar;
3. Tiempo de vencimiento diferencial: cree dos nuevos cachés, maestro A y esclavo B, actualice B primero y luego actualice A, siga estrictamente este orden. Al consultar el caché, primero consulte el caché principal A. Si no hay datos requeridos en A, consulte el caché secundario B.
penetración de caché
Cuando el usuario accede a los datos, los datos no están ni en el caché ni en la base de datos. Como resultado, cuando la solicitud accede al caché, se descubre que falta el caché. Cuando el usuario accede nuevamente a la base de datos, se encuentra que no hay datos a los que acceder en la base de datos y que los datos de la caché no se pueden construir para atender solicitudes posteriores. Luego, cuando llega una gran cantidad de solicitudes de este tipo, la presión de la base de datos aumenta repentinamente, lo que constituye penetración de caché.
La penetración de la caché generalmente ocurre en dos situaciones:
1. Debido a errores de operación comercial, los datos en el caché y los datos de la base de datos se eliminaron, por lo que no había datos en el caché ni en la base de datos;
2. Ataques maliciosos de piratas informáticos. Empresas que acceden deliberadamente a grandes cantidades de datos inexistentes.
solución
1. Limitación de solicitudes ilegales : cuando hay una gran cantidad de solicitudes maliciosas que acceden a datos inexistentes, también se producirá penetración de caché, por lo que en la entrada de la API, debemos determinar si los parámetros de la solicitud son razonables y si los parámetros de la solicitud contiene valores y campos de solicitud ilegales. ¿Existe? Si se determina que es una solicitud maliciosa, se devolverá un error directamente para evitar un mayor acceso al caché y a la base de datos.
2. Establecer un valor nulo o un valor predeterminado : cuando nuestro negocio en línea descubre la penetración de la caché, podemos establecer un valor nulo o un valor predeterminado en la caché para los datos consultados, de modo que las solicitudes posteriores puedan leerlos desde la caché. o los valores predeterminados se devuelven a la aplicación sin continuar consultando la base de datos.
3. Utilice el filtro Bloom para determinar rápidamente si los datos existen y evite consultar la base de datos para determinar si los datos existen : Podemos usar el filtro Bloom para marcar los datos al escribir los datos de la base de datos, y luego, cuando llegue la solicitud del usuario, el hilo de negocios Después de confirmar que el caché no es válido, puede determinar rápidamente si los datos existen consultando el filtro Bloom. Si no existe, no es necesario consultar la base de datos para determinar si los datos existen. Incluso si se produce penetración de caché Una gran cantidad de solicitudes solo consultarán los filtros Redis y Bloom, sin consultar la base de datos, lo que garantiza que la base de datos pueda ejecutarse normalmente. El propio Redis también admite filtros Bloom.
Cabe señalar que los filtros Bloom pueden provocar errores de juicio. En resumen, si el filtro Bloom dice que existe un determinado elemento, existe una pequeña probabilidad de que se juzgue mal. Si el filtro Bloom dice que un elemento no está presente, entonces este elemento no debe estar presente.
Resumir
¿Cómo garantizan las bases de datos y los cachés la coherencia?
¿Debo actualizar primero el caché o la base de datos?
Ignorando los problemas de concurrencia, en circunstancias normales, no importa quién llegue primero, la actualización será exitosa, pero en circunstancias anormales, puede ocurrir [la operación del primer paso tiene éxito y la operación del segundo paso falla].
Problemas de coherencia de datos causados por circunstancias anormales
1. Primero actualice la base de datos y luego actualice el caché.
Si la base de datos se actualiza correctamente pero la actualización del caché falla, entonces el último valor está en la base de datos y el valor anterior está en el caché. Lo que se lee más tarde es el valor anterior. Solo cuando el caché deja de ser válido se puede obtener el valor correcto. de la base de datos.
2. Primero actualice el caché y luego actualice la base de datos.
Si el caché se actualiza correctamente pero la actualización de la base de datos falla, entonces el último valor está en el caché y el valor anterior está en la base de datos. Lo que se lee más tarde es el nuevo valor en el caché. Sin embargo, cuando el caché deja de ser válido, el El valor anterior se lee de la base de datos.
Problemas de coherencia causados por la concurrencia
1. Primero actualice la base de datos y luego actualice el caché.
Si hay dos solicitudes, solicitud A y solicitud B, actualizando los mismos datos al mismo tiempo, puede ocurrir la siguiente situación:
Solicite a A que primero actualice los datos en la base de datos a 1, luego, antes de actualizar el caché, solicite a B que actualice los datos de la base de datos a 2, luego actualice el caché a 2 y luego solicite a A que actualice el caché a 1. En este momento , los datos en la base de datos son 1. Los datos en el caché son 2. Existe una inconsistencia entre los datos en el caché y la base de datos.
solución
1. Utilice bloqueos distribuidos : agregue un bloqueo distribuido antes de actualizar el caché para garantizar que solo se ejecute una solicitud al mismo tiempo para actualizar el caché, de modo que no se produzcan problemas de concurrencia. Por supuesto, después de introducir el bloqueo, el rendimiento de Se mejorará la escritura y el efecto.
2. Establezca el tiempo de vencimiento : después de actualizar el caché, agregue un tiempo de vencimiento más corto al caché . De esta manera, si la inconsistencia del caché ocurre inmediatamente, los datos almacenados en caché caducarán rápidamente, lo que aún es aceptable para la empresa.
2. Primero actualice el caché y luego actualice la base de datos.
Si hay dos solicitudes, solicitud A y solicitud B, actualizando los mismos datos al mismo tiempo, puede ocurrir la siguiente situación:
Una solicitud primero actualiza los datos almacenados en caché a 1 y luego, antes de actualizar la base de datos, llega la solicitud B y actualiza los datos almacenados en caché a 2, luego actualiza la base de datos a 2 y luego A solicita actualizar los datos de la base de datos a 1.
En este momento, los datos en la base de datos son 1, pero los datos en el caché son 2. Existe una inconsistencia entre los datos en el caché y la base de datos.
¿Debo eliminar el caché primero y luego actualizar la base de datos o actualizar la base de datos primero y luego eliminar el caché?
Por lo tanto, ya sea "actualizar la base de datos primero, luego actualizar el caché" o "actualizar el caché primero, luego actualizar la base de datos", ambas soluciones tienen problemas de concurrencia. Cuando dos solicitudes actualizan los mismos datos al mismo tiempo, puede ocurrir un caché. los datos en la base de datos .
En este punto debes considerar otra opción: eliminar el caché. Al actualizar datos, el caché no se actualiza, pero los datos en el caché se eliminan. Luego, al leer los datos, se descubre que no hay datos en el caché, y luego los datos se leen de la base de datos y se actualizan en el caché. Es decir, la estrategia Cache Aside (evitar caché).
Para situaciones anormales, si la operación del segundo paso falla, causará inconsistencia de datos. Aquí nos centramos en la inconsistencia de datos causada por problemas de concurrencia.
Problemas de coherencia causados por la concurrencia
1. Primero elimine el caché y luego actualice la base de datos.
Hay dos solicitudes, solicitando a A que realice una operación de escritura y solicitando a B que realice una operación de lectura.
( 1) Solicite a A que realice una operación de escritura. Después de eliminar el caché de Redis, el trabajo está en progreso. Actualice mysql... ¿A ha actualizado completamente mysql y aún no se ha comprometido?
(2) Solicite a B que inicie la consulta, consulte Redis y descubra que el caché no existe (eliminado de Redis por A)
(3) Solicite a B que continúe y consulte la base de datos para obtener el valor anterior en mysql (A aún no se ha actualizado)
(4) Solicite a B que vuelva a escribir el valor anterior en el caché de Redis
(5) Solicite a A que escriba nuevos valores en la base de datos mysql
En la situación anterior, pueden producirse inconsistencias en los datos.
solución
1. Eliminación doble retrasada : después de que el subproceso A elimina el caché y actualiza la base de datos, "duerme por un tiempo" y luego "borra" el caché.
#删除缓存
redis.delKey(X)
#更新数据库
db.update(X)
#睡眠
Thread.sleep(N)
#再删除缓存
redis.delKey(X)Se agrega un tiempo de suspensión, principalmente para garantizar que cuando la solicitud A esté suspendida, la solicitud B pueda completar la operación de "leer datos de la base de datos y luego escribir el caché faltante en el caché" durante este período de tiempo, y luego solicitar A que terminar de dormir. y luego eliminar el caché.
Por lo tanto, el tiempo de inactividad de la solicitud A debe ser mayor que el tiempo de "leer datos de la base de datos + escribir en el caché" de la solicitud B.
2. Primero actualice la base de datos y luego elimine el caché.
Continúe analizando el uso del escenario de concurrencia de solicitudes de "lectura + escritura".
Si ciertos datos de usuario no existen en el caché, la solicitud A consulta la edad de la base de datos para que sea 20 al leer los datos, y otra solicitud B actualiza los datos cuando no están escritos en el caché. Actualiza la edad en la base de datos a 21 y borra el caché. En este momento, se solicita a A que escriba en la memoria caché los datos con 20 años de antigüedad leídos de la base de datos.
Finalmente, la edad del usuario es 20 (valor anterior) en el caché y 21 (valor nuevo) en la base de datos. Los datos del caché y de la base de datos son inconsistentes.
Según el análisis teórico anterior, actualizar la base de datos primero y luego eliminar el caché también causará inconsistencia en los datos, pero en la práctica, la probabilidad de que ocurra este problema no es alta .
Debido a que la escritura en caché suele ser mucho más rápida que la escritura en la base de datos , en la práctica es difícil tener una situación en la que la solicitud B ya haya actualizado la base de datos y eliminado el caché, y la solicitud A acaba de actualizar el caché.
Una vez que la solicitud A actualiza el caché antes de que la solicitud B lo elimine, la solicitud posterior volverá a leer los datos de la base de datos debido a una pérdida de caché, por lo que esta inconsistencia no ocurrirá.
¿Cómo asegurar el éxito en ambos pasos?
Analizamos anteriormente que ya sea que se trate de actualizar el caché o eliminarlo, siempre que el segundo paso falle, provocará una inconsistencia entre la base de datos y el caché.
1. Mecanismo de reintento
Puede introducir una cola de mensajes , agregar los datos que se operarán en la segunda operación (eliminación de caché) a la cola de mensajes y dejar que el consumidor opere los datos.
- Si la aplicación no puede eliminar el caché , puede volver a leer los datos de la cola de mensajes y luego eliminar el caché nuevamente: este es el mecanismo de reintento . Por supuesto, si el reintento excede un cierto número de veces y aún falla, debemos enviar un mensaje de error a la capa empresarial.
- Si el caché se elimina con éxito , los datos deben eliminarse de la cola de mensajes para evitar operaciones repetidas. De lo contrario, continúe intentándolo nuevamente.
2. Suscríbase al registro de cambios de la base de datos:
El primer paso de la estrategia " actualizar la base de datos primero y luego eliminar el caché " es actualizar la base de datos. Si la base de datos se actualiza correctamente, se generará un registro de cambios que se registrará en el binlog.
Por lo tanto, podemos obtener datos específicos para operar suscribiéndonos al registro binlog y luego eliminando el caché.
Resumir
Referencia del artículo:
2. Codificación Xiaolin: introducción ilustrada a Redis | Codificación Xiaolin
3. Combate real de Shang Silicon Valley Redis7: Shang Silicon Valley Redis de cero básico a avanzado, el tutorial de redis7 más sólido, Yang Ge dirige personalmente la práctica (con preguntas de la entrevista de redis)_bilibili_bilibili
4.javaguide: Guía de entrevistas de Java | JavaGuide (Entrevista de Java + Guía de estudio)
5. Cuenta oficial de Water Droplet y Silver Bullet: problemas de coherencia de la base de datos y el almacenamiento en caché, solo lea este artículo (qq.com)