Wie Meta trotz Cache-Invalidierung Cache-Konsistenz aufrechterhält (Übersetzung)

Cache-Inkonsistenz

• Ein Cache-Server sendet eine Anfrage für x an die DB, und bevor die Antwort x=42 den Cache erreicht
  • wird x extern auf x=43 aktualisiert, und per Invalidierung wird x=43 an den Cache übermittelt
  • der Cache empfängt x=43 und übernimmt den Wert
  • die Antwort x=42 trifft verspätet ein und wird angewendet
• Dieses Problem lässt sich lösen, indem man Daten mit einer Version versieht
• Aber selbst mit Versionen kann nach einer Eviction von x=43 wieder x=42 übernommen werden

Polaris: Messdienst für Cache-Inkonsistenz

• Ablauf
  • Polaris empfängt ebenfalls Invalidierungs-Events
  • Wenn ein Event eintrifft, prüft Polaris auf allen Cache-Servern, ob noch eine ältere Version vorhanden ist
  • Wenn ein Cache noch eine ältere Version hat, wird dies als Inkonsistenz gewertet und zur erneuten Verarbeitung in die Queue gestellt
    • denn das Invalidierungs-Event kann einen Cache-Server verspätet erreichen
  • Nach einer bestimmten Zeit (z. B. 1, 3 oder 5 Minuten) wird ein Inkonsistenz-Alarm gesendet
• Metrik
  • Die Metrik zeigt, ob Cache-Schreibvorgänge in den letzten M Minuten die Konsistenz von N Nines erreichen
  • Bei 10 Nines über 5 Minuten bedeutet das, dass in den letzten 5 Minuten 1 von 10 Milliarden Cache-Schreibvorgängen inkonsistent war

Logging-Bibliothek zum Debuggen von Cache-Inkonsistenz

• Es ist nicht möglich, alle Cache-Schreibvorgänge zu loggen
  • denn ein Cache hat von Haus aus eine read-heavy workload, würde durch „Logging“ aber zu einer write-heavy workload werden
• Deshalb wurde eine Bibliothek entwickelt, die Logging für das Zeitfenster direkt nach einer Invalidierung ermöglicht
• Die Bibliothek wurde in alle Services eingebaut, die an der Invalidierung beteiligt sind
• Wenn durch das Logging eine Inkonsistenz auftritt, lässt sich der Ablauf bis zu ihrem Auftreten als Timeline nachvollziehen