한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Libro blanco del lag en juegos › L12 Base de datos

Estampida de caché Cache stampede / thundering herd

ID de la causa db-cache-stampede · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)

Abrir la ficha interactiva con gráficos y simulaciones →

Si la caché de unos datos populares caduca a la vez, miles de solicitudes se lanzan de golpe contra la BD.

Por qué Los datos populares guardados en Redis u otra caché caducan a la vez → Efecto Las solicitudes que intentan regenerar esos mismos datos se lanzan de golpe contra la BD → En pantalla Por la sobrecarga de la BD, varias funciones se ralentizan o se congelan una tras otra

Síntomas
Input lag, Congelamiento, No conecta / carga infinita
Factores
Detención, Latencia
A quién afecta
Todo el servidor
Cuándo
A intervalos regulares, Cuando se junta mucha gente
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Repartir al azar la hora de caducidad, dejar que solo una solicitud regenere el dato y que las demás usen el valor antiguo.
Tareas (Equipo de infraestructura)
Configurar réplicas y failover automático para que la caché no se vacíe entera cuando Redis se reinicia o falla, comprobar que la BD tiene margen para aguantar con la caché vacía.
En el gráfico
Picos periódicos · Tasa de aciertos de la caché, consultas por segundo de la BD
Dónde mirar
keyspace_hits y keyspace_misses (tasa de aciertos), expired_keys y reinicios (uptime_in_seconds) de INFO de Redis, superpuestos a las consultas por segundo de la BD; contar cuántas consultas iguales se ejecutan a la vez en la BD en ese momento (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity)
Se confirma si
Cuando los fallos de caché se disparan de repente, las consultas a la BD también se disparan, y la mayoría de las consultas simultáneas son la misma consulta que lee los mismos datos. Coincide con el ciclo de caducidad de una clave popular o con un reinicio de Redis
Se descarta si
Si los fallos de caché son los normales pero solo aumentan las consultas a la BD, apunta a una avalancha de inicios de sesión (db-login-storm) o a procesos batch (db-batch)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Lo mismo ocurre si Redis se reinicia o falla y la caché se vacía entera. Cuanto más pequeña se haya dimensionado la BD confiando en la caché, mayor es el riesgo.

Fuentes

  1. Scaling Memcache at Facebook (NSDI '13) USENIX
    Cuando se invalida una clave muy usada, muchas lecturas se lanzan contra la BD (thundering herd); se evita con leases (solo un cliente regenera el dato) y devolviendo valores antiguos; los clústeres con la caché vacía se precalientan aparte
  2. Optimal Probabilistic Cache Stampede Prevention VLDB Endowment
    Cuando un elemento popular caduca, varias solicitudes lo regeneran a la vez (estampida de caché); se evita regenerándolo de forma probabilística antes de que caduque
  3. High availability with Redis Sentinel Redis
    Failover automático que promueve una réplica cuando cae el servidor principal
  4. INFO Redis
    keyspace_hits y keyspace_misses (búsquedas de claves con y sin éxito), expired_keys (claves caducadas), uptime_in_seconds (tiempo desde el arranque)
  5. SHOW PROCESSLIST Statement MySQL
    La sentencia que ejecuta cada sesión (Info) y el tiempo que lleva en su estado actual (Time, en segundos)
  6. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    pg_stat_activity: la consulta que cada sesión está ejecutando (query)

Ver también

Misma capa: L12 Base de datos

Causas de otras capas con el mismo síntoma (Input lag)

Ver la ficha interactiva con gráficos y simulaciones