Geschichte der Frage.
Advisory Locks erschienen erstmals in PostgreSQL 8.2, um leichte, anwendungsbasierte Synchronisationsprimitive bereitzustellen, die außerhalb des MVCC-Tuple-Sichtbarkeitssystems arbeiten. Sie wurden für Arbeitsabläufe wie die Verarbeitung von Warteschlangen und idempotente Eingaben entwickelt, bei denen ein zeilenbasierter Lock semantisch unangemessen oder leistungshemmend wäre. Im Gegensatz zu zeilenbasierten Locks, die an bestimmte Tabellen-Tupel gebunden sind und in der xmax-Systemspalte aufgezeichnet werden, befinden sich Advisory Locks vollständig im Shared-Memory-Lock-Manager, der einen Mechanismus bietet, um den Zugriff auf abstrakte Ressourcen zu steuern, ohne tote Tupel oder WAL-Traffic zu erzeugen.
Das Problem.
In stark frequentierten idempotenten Eingabepipelines verursacht die Durchsetzung der Eindeutigkeit von Geschäftsschlüsseln (z. B. externen UUIDs) durch herkömmliche INSERT ... ON CONFLICT oder SELECT FOR UPDATE schwerwiegende Engpässe. Zeilenbasierte Ansätze erfordern Schreibzugriffe auf den Heap, um Lock-Bits zu setzen, was Tabellen aufbläht, den VACUUM-Druck erhöht und Hotspots in eindeutigen Indizes während der Konfliktauflösung verursacht. Die Herausforderung besteht darin, gegenseitigen Ausschluss für logische Entitäten – wie z. B. einen gehashten Geschäftsschlüssel – bereitzustellen, ohne die Speicherebene zu berühren, und gleichzeitig sicherzustellen, dass Lock-Fehler keine Ressourcen in persistenten Verbindungs-Pools hinterlassen.
Die Lösung.
Die entscheidende Eigenschaft ist, dass Advisory Locks ausschließlich in der LOCKTAG-Hash-Tabelle im Shared Memory gespeichert werden, unter Verwendung von LOCKMETHOD_ADVISORY, und somit niemals die zugrunde liegenden Relation-Seiten ändern. Durch die Verwendung von pg_advisory_xact_lock(hashtext(business_key)) erwirbt die Anwendung einen transactionspezifischen Mutex, der automatisch bei COMMIT oder ROLLBACK freigegeben wird, wodurch das Lock-Leck, das mit sessionbasierten pg_advisory_lock verbunden ist, verhindert wird. Dieser Ansatz beseitigt die Tabellenausdehnung und Indexkonkurrenz, da das Lock nur als leichter Eintrag im Speicher existiert, wie unten gezeigt:
BEGIN; -- Erwirb ein transaction bound Lock auf den gehashten Geschäftsschlüssel SELECT pg_advisory_xact_lock(hashtext('a1b2c3d4')); -- Sicher, einzufügen; keine einzigartige Indexpunktrivalität, wenn eine andere Sitzung das Lock hält INSERT INTO events (business_key, payload) VALUES ('a1b2c3d4', '{"event":"click"}') ON CONFLICT (business_key) DO NOTHING; COMMIT;
Das Datenplattformteam eines Telemetrieunternehmens benötigte die Garantie einer genau einmaligen Verarbeitung für 50.000 Ereignisse pro Sekunde, die aus Kafka in PostgreSQL eingespeist wurden, wobei jedes Ereignis einen vom Client generierten UUID trug, der als Idempotenzschlüssel diente. Erste Lasttests unter Verwendung von INSERT ... ON CONFLICT DO NOTHING auf einer einzigartigen UUID-Spalte verursachten schwerwiegende Verzögerungen aufgrund von Spinlock-Konkurrenz auf dem einzigartigen B-Tree-Index und schnell ansteigendem Bloat aufgrund von HOT-Update-Fehlern. Die WAL-Generationsrate verdoppelte sich zu Spitzenzeiten, was die Replikationsverzögerung und die Speicherkapazität gefährdete.
Ein vorgeschlagener Fix bestand darin, die Schlüsselexistenz vorab zu überprüfen, indem SELECT * FROM events WHERE business_key = $1 FOR UPDATE verwendet wurde, und dann nur einzufügen, wenn das Ergebnis leer war. Obwohl dies Duplikate verhinderte, zwang es jeden Schreiber, ein Zeilenlock auf entweder die vorhandene Zeile oder eine Ersatzreservierungszeile zu erwerben, was einen massiven Hotspot auf den Seiten der Reservierungstabelle schuf. Der Ansatz erzeugte erhebliche Tabellenausdehnung – was erforderte, dass VACUUM alle fünfzehn Minuten tote Tupel zurückgewinnen konnte – und konnte keine Wettlaufbedingungen zwischen der Überprüfung und dem Einfügen verhindern, ohne das Lock die gesamte Transaktionsdauer zu halten, was den Durchsatz erheblich beschränkte.
Das Architektureteam schlug vor, die Koordination in einen externen Redis-Cache zu verlagern, indem SETNX-Operationen verwendet wurden, um Einfügungen zu steuern. Dies beseitigte den Datenbankbloat und reduzierte die Belastung von PostgreSQL, führte jedoch zu kritischen Fehlermodi: Netzwerkpartitionen zwischen dem Redis-Cluster und der Datenbank konnten doppelte Einfügungen ermöglichen, wenn das Redis-Lock abgelaufen war, die PostgreSQL-Transaktion jedoch noch nicht abgeschlossen war. Darüber hinaus führte die Aufrechterhaltung der Konsistenz über zwei verteilte Systeme hinweg zu operativer Komplexität und erforderte die Implementierung von Redlock oder ähnlichen Algorithmen, was die Latenz pro Operation um etwa 5 Millisekunden erhöhte.
Das gewählte Design nutzte die nativen Advisory Locks von PostgreSQL über pg_advisory_xact_lock(hashtext(business_key)), um ein transaction bound Lock auf die gehashte UUID zu erwerben, bevor versucht wurde, die Eingabe durchzuführen. Da diese Locks nur im Shared Memory leben und nicht den Heap berühren, verursachen sie null Speicherungslasten und werden automatisch bei Transaktionsbeendigung freigegeben, wodurch das Lock-Leck verhindert wird, das mit sessionbasierten Locks beobachtet wurde. Um nicht erkennbare Deadlocks zu vermeiden, sortierte die Anwendungsebene alle UUIDs in jedem Batch nach ihrem gehashten Ganzzahlwert, bevor Locks erworben wurden, um ein globales Bestellprotokoll über alle konkurrierenden Arbeiter sicherzustellen.
Advisory Locks wurden ausgewählt, weil sie die niedrigste Latenz (unter Millisekunden-Akquisition) und null Speicherungseffekte boten, während sie strikte Korrektheit ohne externe Abhängigkeiten gewährleisteten. Im Gegensatz zu dem Redis-Ansatz war die Lebensdauer des Locks an die Datenbanktransaktion gebunden, was die Atomizität zwischen Lock-Akquisition und Einfügetransaktion garantierte. Im Gegensatz zu SELECT FOR UPDATE wurde keine Tabellenausdehnung erzeugt, und im Gegensatz zu rohem ON CONFLICT wurde der einzigartige Index niemals durch widersprüchliche gleichzeitige Einfügungen belastet, da die Serialisierung vor dem Heap-Zugriff stattfand.
Nach der Bereitstellung hielt die Eingabepipeline 80.000 Ereignisse pro Sekunde mit p99 Latenz unter 10 Millisekunden aufrecht, verglichen mit vorherigen 200ms-Spitzen während der Konkurrenzspitzen. Der Tabellenausdehnung sank auf vernachlässigbare Werte, so dass autovacuum nur während der Nebenzeiten ausgeführt wurde, und das WAL-Volumen sank um 40 %, was die Archivierungskosten und die Replikationsverzögerung erheblich reduzierte. Das System hielt die genau einmaligen Semantiken während mehrerer Datenbankneustarts und Poolwechsel ohne ein einziges Duplikatereignis oder Deadlock-induzierte Zeitüberschreitungen aufrecht.
Warum birgt die Verwendung von pg_advisory_lock (sessionspezifisch) statt pg_advisory_xact_lock das Risiko der Erschöpfung des Verbindungs-Pools und der doppelten Eingabe in einer Hochdurchsatz-Arbeiterarchitektur?
Kandidaten erkennen häufig nicht, dass pg_advisory_lock bestehen bleibt, bis es ausdrücklich freigegeben oder die Sitzung getrennt wird, selbst wenn die Transaktion abgebrochen wird. In einer Pool-Umgebung, in der Arbeiter langanhaltende Verbindungen wiederverwenden, lässt ein Logikfehler oder eine Ausnahme, die den Unlock-Aufruf umgeht, das Lock unbefristet gehalten, wodurch nachfolgende Arbeiter, die denselben Geschäftsschlüssel verarbeiten, ewig warten. Stattdessen sollte pg_advisory_xact_lock verwendet werden, da es die Lebensdauer des Locks an die Transaktionsgrenze bindet, was eine automatische Freigabe bei ROLLBACK gewährleistet und das Mutex-Leck verhindert, das andernfalls den Arbeiter-Pool austrocknen und die Eingabepipeline zum Stillstand bringen würde.
Wie führt das Fehlen einer Gesamtordnungsgarantie beim Erwerb mehrerer Advisory Locks zu nicht erkennbaren Deadlocks, und welches spezifische Anwendungsbeispiel beseitigt dieses Risiko?
Im Gegensatz zu zeilenbasierten Deadlocks, die der PostgreSQL-Deadlock-Zeitüberschreiter durch das Töten einer Opfertransaktion löst, sind Advisory Lock-Deadlocks für die Engine unsichtbar, da sie in benutzerdefinierten Namensräumen auftreten. Wenn Arbeiter A Ressource X und dann Y sperrt, während Arbeiter B Y und dann X sperrt, warten beide Sitzungen ewig, ohne einen Fehler. Das obligatorische Muster besteht darin, alle Ressourcen-Identifikatoren (z. B. hashtext(uuid)-Werte) vor der Ausgabe von Lock-Anfragen in strikter monotoner Reihenfolge (aufsteigend oder absteigend) über die gesamte Anwendung zu sortieren. Diese globale Ordnung stellt sicher, dass Wartegraphen azyklisch bleiben, was zirkuläre Abhängigkeiten unmöglich macht und das Risiko von stillen Blockaden beseitigt.
Welche Einschränkung des Shared Memory beschränkt die Anzahl der Advisory Locks, die eine einzelne Transaktion halten kann, und wie äußert sich das Überschreiten von max_locks_per_transaction im Vergleich zur Erschöpfung von zeilenbasierten Locks?
Viele Kandidaten nehmen an, dass Advisory Locks unbegrenzt sind, aber sie verbrauchen Einträge in der gemeinsamen Lock-Tabelle, die durch den Konfigurationsparameter max_locks_per_transaction (Standard 64) gesteuert werden. Das Halten von mehr Locks als dieses Limit in einer Transaktion führt zu ERROR: out of shared memory (SQLSTATE 53200), was die Transaktion sofort abbricht. Dies steht im Gegensatz zu zeilenbasierten Locks, bei denen ein Überschreiten der Grenzen in der Regel ein Lock-Upgrading oder ein Warten auslöst, abhängig von lock_timeout, jedoch nicht einen festen Shared Memory-Pool erschöpft. Die Minderung besteht darin, Operationen in kleinere Untertransaktionen zu bündeln oder mehrere logische Ressourcen unter einem einzigen Advisory Lock-Schlüssel über komposite Hashes zu aggregieren, anstatt zu versuchen, Tausende von einzelnen Schlüsseln gleichzeitig zu sperren.