Transaktionsbewusste Cache-Invalidierung in PostgreSQL
Dieser Leitfaden erklärt, wie Trigger an angehängten Tabellen verhindern, dass auf einen bestätigten PostgreSQL-Schreibvorgang ein veralteter RESP-Cache-Treffer folgt.
Ein Trigger erfasst geänderte Schlüssel oder eine geänderte Relation innerhalb der Schreibtransaktion. Beim Commit veröffentlicht die Erweiterung Invalidation-Fences und erhöht Generationen. Eine Befüllung, die vor dem Fence begonnen hat, kann keine veralteten Daten veröffentlichen. Ein Rollback vor der Fence-Veröffentlichung verwirft den Änderungszustand der Transaktion; vorherige Cache-Einträge bleiben gültig. Wird die Transaktion nach der Veröffentlichung abgebrochen, wird die Invalidierung nicht rückgängig gemacht und betroffene Einträge bleiben ungültig.
Den vollständigen Vertrag des Lesewegs finden Sie in der technischen Referenz zur Konsistenz.
Invalidierung über SQL und RESP prüfen
Starten Sie die lokale Demo und lesen Sie denselben Schlüssel über RESP und PostgreSQL:
MGET CRUD:pglc_demo.public.items:{"id":42}
Aktualisieren und bestätigen Sie den Eintrag in einer separaten SQL-Sitzung:
BEGIN;
UPDATE public.items SET revision = revision + 1 WHERE id = 42;
COMMIT;
Der nächste RESP-Befehl liefert die bestätigte Revision. Wird die Schreibtransaktion stattdessen zurückgerollt, liefert RESP weiterhin die letzte bestätigte Revision.
RESP verwendet die konfigurierte PostgreSQL-Rolle in einer unabhängigen kurzen Transaktion. Rolle, Transaktion und Snapshot der Anwendung werden nicht geteilt. Verwenden Sie für Read-your-writes und SELECT ... FOR UPDATE SQL innerhalb der Anwendungstransaktion.
Fälle, in denen der Cache umgangen wird
Ist pg_local_cache.enabled deaktiviert, überspringt RESP MGET Cache-Suche und Befüllung und liest aus der Quelltabelle. Ein aktiver Dirty Fence für einen Schlüssel, eine Relation oder global blockiert ebenfalls Cache-Treffer und Befüllungen; die Lesevorgänge verwenden dann die Quelltabelle. RESP-Worker starten erst nach Ende der Recovery; Recovery ist daher keine eigene Umgehungsbedingung. Eine Zeile, die nicht in einen Cache-Eintrag passt, kann trotzdem aus PostgreSQL zurückgegeben werden, wenn ihr JSON innerhalb des RESP-Wertlimits liegt, wird aber nicht gespeichert.
Ursache eines Fehltreffers prüfen
Vergleichen Sie local_cache.stats() und local_cache.health() vor und nach einer kontrollierten Arbeitslast. Prüfen Sie Zähler für Bypass, Fehltreffer, Invalidierung und das Neuladen von Zuordnungen. Siehe die technische Metrikliste.
Aktualisiert .