c. Stampede

Um cache stampede (também chamado de thundering herd ou dog-piling) acontece quando uma chave quente expira: toda requisição que chega antes de o valor ser reconstruído dá miss, e todas rodam a mesma consulta cara ao mesmo tempo. O banco, que o cache estava protegendo, recebe uma rajada de trabalho idêntico exatamente quando o tráfego está no auge.

sequenceDiagram
    autonumber
    participant F1 as Fã 1
    participant F2 as Fãs 2..200
    participant C as catalog ×3
    participant R as redis
    participant DB as db
    Note over R: a chave "São Paulo, página 0" expira
    F1->>C: GET da listagem
    C->>R: GET → miss
    C->>DB: consulta pesada (join, sort, count)
    F2->>C: GET da listagem (mesma chave, mesmo instante)
    C->>R: GET → miss
    C->>DB: a MESMA consulta pesada, ×199
    Note over DB: 200 consultas idênticas, pool de 30 conexões: fila
    DB-->>C: linhas (algum dia)
    C->>R: SET (200 vezes, mesmo valor)

1. Reproduza

Torne o problema frequente: uma listagem quente com TTL de 3 s, martelada por 200 usuários em modelo fechado, sem tempo de pensar.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Lab 5: cache stampede. 200 fans refresh the SAME expensive page non-stop.
// Every time its key expires, how many requests go to the database at once?
//   CACHE_TTL_LIST=3s docker compose up -d      (short TTL: many expirations per minute)
//   k6 run load/stampede.js
import http from 'k6/http';
import { check } from 'k6';
import { Counter } from 'k6/metrics';

const BASE_URL = __ENV.BASE_URL || 'http://localhost';
const misses = new Counter('cache_misses');          // each MISS = one heavy query in the DB

export const options = {
  vus: Number(__ENV.VUS || 200),
  duration: __ENV.DURATION || '1m',
  summaryTrendStats: ['avg', 'med', 'p(95)', 'p(99)', 'max'],
  thresholds: {
    cache_misses: ['count>=0'],                       // printed in the summary
    http_req_failed: ['rate<0.01'],
  },
};

const HOME = `${BASE_URL}/catalog/events?city=${encodeURIComponent('São Paulo')}&page=0`;

export default function () {
  const res = http.get(HOME, { tags: { name: 'home' } });
  check(res, { 'home is 200': (r) => r.status === 200 });
  if (res.headers['X-Cache'] !== 'HIT') {
    misses.add(1);
  }
}

CACHE_TTL_LIST=3s CACHE_STAMPEDE_PROTECTION=false docker compose up -d --wait
k6 run -q -e DURATION=20s load/stampede.js > /dev/null    # warm-up: the replicas were recreated
k6 run load/stampede.js

Em 60 s a chave expira cerca de 20 vezes. Sem proteção, cache_misses fica muito acima de 20 — cada expiração deixa passar toda requisição que chegou durante a recarga, uma consulta pesada para cada uma. Acompanhe o docker stats durante o teste: a CPU do db dá um pico a cada ~3 segundos, e a latência também (compare max e p(99) com med).

2. Corrija: uma reconstrução por chave

A correção implementada no EventCache (já está no seu código, atrás de uma chave) é um lock distribuído por chave:

1. Miss → tente SET key:lock <token> NX PX 2000. O Redis garante que só uma requisição no cluster inteiro (as três réplicas) o obtém.
2. A vencedora confere o cache de novo, roda a consulta, escreve o valor e libera o lock.
3. As perdedoras não consultam o banco: elas consultam o cache a cada 25 ms por até 500 ms e devolvem o valor assim que a vencedora o escreve (um HIT).
4. Se a vencedora morrer, o lock expira depois de 2 s, então ninguém espera para sempre.

if (stampedeProtection) {
    var lockKey = key + ":lock";
    var token = UUID.randomUUID().toString();
    if (tryLock(lockKey, token)) {
        try {
            cached = read(key);               // someone may have filled it meanwhile
            if (cached != null) {
                return count(new Result(cached, "HIT"));
            }
            return count(load(key, ttl, loader));
        } finally {
            unlock(lockKey, token);
        }
    }
    // another request is already loading this key: wait for it instead of
    // sending one more identical query to the database
    for (int i = 0; i < 20; i++) {
        sleep(Duration.ofMillis(25));
        cached = read(key);
        if (cached != null) {
            return count(new Result(cached, "HIT"));
        }
    }
}

CACHE_TTL_LIST=3s CACHE_STAMPEDE_PROTECTION=true docker compose up -d --wait
k6 run -q -e DURATION=20s load/stampede.js > /dev/null    # warm-up: the replicas were recreated
k6 run load/stampede.js

Agora cache_misses deve ficar perto do número de expirações (~20 por minuto). Numa execução de teste deste script como está (200 VUs, 60 s, TTL de 3 s), os misses caíram de 2.238 para 19 — uma consulta ao banco por expiração em vez de cerca de cento e dez. Na mesma execução o p99 caiu de cerca de 1 s para cerca de 0,3 s e a CPU média do db, de 234% para 4%. O ganho de latência varia de máquina para máquina (o Redis, o edge e o gateway também pesam em cada requisição), mas a carga no banco durante cada expiração cai cerca de duas ordens de grandeza, e é isso que o protege durante um pico real. Preencha a tabela do stampede em results/lab5.md.

3. Outras curas, e os seus trade-offs

Volte à visão geral do lab para registrar os resultados.