¿Cómo pueden fallar los sistemas de caché?

El siguiente diagrama muestra 4 casos típicos en los que las cachés pueden salir mal y sus soluciones.

1. El problema de la manada de truenos
Esto sucede cuando un gran número de claves de la memoria caché caducan al mismo tiempo. A continuación, las solicitudes de consulta llegan directamente a la base de datos, lo que sobrecarga la base de datos.

Hay dos formas de mitigar este problema: una es evitar establecer el mismo tiempo de caducidad para las claves, agregando un número aleatorio en la configuración; La otra es permitir que solo los datos empresariales principales lleguen a la base de datos y evitar que los datos no esenciales accedan a la base de datos hasta que se realice una copia de seguridad de la memoria caché.

2. Penetración de caché
Esto sucede cuando la clave no existe en la memoria caché o en la base de datos. La aplicación no puede recuperar datos relevantes de la base de datos para actualizar la memoria caché. Este problema crea mucha presión tanto en la memoria caché como en la base de datos.

Para resolver esto, hay dos sugerencias. Una es almacenar en caché un valor nulo para claves inexistentes, evitando llegar a la base de datos. La otra es usar un filtro de bloom para verificar primero la existencia de la clave, y si la clave no existe, podemos evitar golpear la base de datos.

3. Desglose de la caché
Esto es similar al problema de la manada del trueno. Ocurre cuando caduca una tecla de acceso rápido. Un gran número de solicitudes llegan a la base de datos.

Dado que las teclas de acceso rápido ocupan el 80% de las consultas, no establecemos un tiempo de caducidad para ellas.

4. Bloqueo de caché
Esto sucede cuando la caché está inactiva y todas las solicitudes van a la base de datos.

Hay dos formas de resolver este problema. Una es configurar un disyuntor y, cuando la memoria caché está inactiva, los servicios de la aplicación no pueden visitar la memoria caché ni la base de datos. La otra es configurar un clúster para la memoria caché con el fin de mejorar la disponibilidad de la memoria caché.

Te toca a ti: ¿Te has encontrado con alguno de estos problemas en la producción?

IT support 😂

El registro, el rastreo y las métricas son 3 pilares de la observabilidad del sistema.

El siguiente diagrama muestra sus definiciones y arquitecturas típicas.

🔹 Logging
El registro registra eventos discretos en el sistema. Por ejemplo, podemos registrar una solicitud entrante o una visita a bases de datos como eventos. Tiene el volumen más alto. La pila ELK (Elastic-Logstash-Kibana) se usa a menudo para crear una plataforma de análisis de logs. A menudo definimos un formato de registro estandarizado para que lo implementen diferentes equipos, de modo que podamos aprovechar las palabras clave al buscar entre cantidades masivas de registros.

🔹 Tracing
Normalmente, el seguimiento se basa en el ámbito de la solicitud. Por ejemplo, una solicitud de usuario pasa por la puerta de enlace de API, el equilibrador de carga, el servicio A, el servicio B y la base de datos, que se pueden visualizar en los sistemas de seguimiento. Esto es útil cuando intentamos identificar los cuellos de botella en el sistema. Utilizamos OpenTelemetry para mostrar la arquitectura típica, que unifica los 3 pilares en un solo marco.

🔹 Métricas
Las métricas suelen ser información agregable del sistema. Por ejemplo, QPS de servicio, capacidad de respuesta de API, latencia de servicio, etc. Los datos sin procesar se registran en bases de datos de series temporales como InfluxDB. Prometheus extrae los datos y los transforma en función de reglas de alerta predefinidas. Luego, los datos se envían a Grafana para su visualización o al administrador de alertas, que luego envía notificaciones o alertas por correo electrónico, SMS o Slack.

Depende de usted: ¿Qué herramientas ha utilizado para la supervisión del sistema?

Si quieren aprender un poco mas sobre Observabilidad deben tener esto siempre presente