Como a Meta mantém a consistência do cache usando invalidação de cache (tradução)

Inconsistência de cache

• o servidor de cache envia uma solicitação sobre x ao banco de dados, e antes de a resposta do banco com x=42 chegar ao cache
  • externamente, x é atualizado para x=43, e x=43 é enviado ao cache por meio de invalidação
  • o cache recebe x=43 e aplica a mudança
  • a resposta x=42 chega atrasada e é aplicada
• o problema acima pode ser resolvido adicionando uma versão aos dados
• porém, mesmo adicionando uma versão, se ocorrer uma eviction de x=43, x=42 pode ser aplicado

Polaris: serviço de medição de inconsistência de cache

• processo de funcionamento
  • o Polaris também recebe eventos de invalidação
  • ao receber um evento, ele consulta todos os servidores de cache para verificar se ainda possuem a versão anterior
  • se o cache tiver a versão anterior, isso é considerado uma inconsistência, e o evento é reenfileirado para permitir nova tentativa
    • porque o evento de invalidação pode chegar atrasado ao servidor de cache
  • após um certo tempo (1 minuto, 3 minutos, 5 minutos etc.), envia um alerta de inconsistência
• métricas
  • exibe uma métrica mostrando se as gravações no cache correspondentes a N nines foram consistentes nos últimos M minutos
  • se forem 10 nines em 5 minutos, é possível saber que, nos últimos 5 minutos, 1 entre 10 bilhões de gravações no cache foi inconsistente

Biblioteca de logging para depurar inconsistência de cache

• é impossível registrar em log todas as gravações no cache
  • porque, originalmente, o cache tem um workload com predominância de leitura, mas o "logging" o transformaria em um workload com predominância de escrita
• por isso, foi criada uma biblioteca que permite fazer logging da janela de tempo logo após ocorrer uma invalidação
• a biblioteca é incorporada em todos os serviços envolvidos na invalidação
• por meio do logging, quando ocorre uma inconsistência, é possível identificar em uma timeline o processo até ela acontecer