Optimistisches oder pessimistisches Sperren: Welche Methode sollte bei Buchungen oder beim Checkout verwendet werden?

Verwenden Sie pessimistisches Sperren, wenn viele Benutzer um dieselbe Zeile konkurrieren, wie bei den letzten Tickets eines Events. Verwenden Sie optimistisches Sperren mit einem Versionsfeld, wenn Konflikte selten sind, wie bei Buchungen oder Warenkörben, die sich über viele Slots und Produkte verteilen. Die Wahl hängt davon ab, wie oft realistisch zwei Schreibvorgänge dieselbe Zeile treffen.

Was ist der Unterschied zwischen optimistischem und pessimistischen Sperren?

Pessimistisches Sperren blockiert andere Schreibvorgänge, solange eine Transaktion eine Zeile hält, sodass Konflikte warten müssen. Optimistisches Sperren lässt alle Vorgänge fortfahren und lehnt eine Schreiboperation ab, wenn sich das Versionsfeld darunter geändert hat, wodurch Konflikte einen erneuten Versuch auslösen. Die erste Methode tauscht Latenz gegen Sicherheit; die zweite tauscht gelegentliche Wiederholungen gegen kein Warten.

Wann ist optimistisches Sperren die bessere Wahl?

Optimistisches Sperren ist vorteilhaft, wenn Schreibvorgänge kurz sind und Kollisionen selten auftreten. Bei Trexinds Buchungsslots sorgt ein Versionsfeld dafür, dass der Schreibvorgang, der im Rennen verliert, einen Konflikt erhält und gegen den aktuellen Slot-Status erneut versucht wird, anstatt still überschrieben zu werden. Ein Lock, der über die gesamte Anfrage gehalten wird, würde mehr kosten als er spart.

Wann ist pessimistisches Sperren die bessere Wahl?

Pessimistisches Sperren ist sinnvoll bei einer einzelnen stark umkämpften Zeile, die viele Käufer gleichzeitig wollen, wie die letzten Tickets eines beliebten Events. Dort führen optimistische Wiederholungen zu starker Belastung und zwingen jeden Verlierer, den gesamten Checkout erneut durchzuführen. Ein kurzer Lock lässt den zweiten Käufer nur wenige Millisekunden warten und dann sehen, dass ausverkauft ist.

Wie entscheiden Sie für Ihr eigenes System?

Fragen Sie, wie oft zwei Schreibvorgänge dieselbe Zeile treffen und was ein verlorenes Rennen für den Nutzer kostet. Seltene Kollisionen und günstige Wiederholungen sprechen für optimistisches Sperren. Häufige Kollisionen auf einer Zeile oder Wiederholungen, die teure Arbeit erneut ausführen, sprechen für pessimistisches Sperren. Messen Sie die Konkurrenz, bevor Sie sich festlegen; dieselbe Anwendung kann beide Methoden nutzen.

• Viele Zeilen, wenige Kollisionen pro Zeile: optimistisch (Bestände über hunderte SKUs)

• Eine Zeile, viele gleichzeitige Schreiber: pessimistisch (letzte Tickets eines Events)

• Schreiben erfolgt einmal pro Entität: ein kurzer Lock ist ausreichend (Prüfungseinreichung)

Auf einen Blick

• Letzte Tickets eines Events (FindYourVibe) · Hoch: ein Ansturm auf eine Zeile · Pessimistischer Zeilensperre · Der Verlierer wartet Millisekunden statt den gesamten Checkout erneut zu versuchen

• Termin- und Tischslots (Trexind) · Niedrig: kurze Schreibvorgänge, selten umkämpft · Optimistisches Versionsfeld · Ein Lock über die gesamte Anfrage lohnt wegen der Latenz nicht

• Bestände über viele SKUs (Skyxis) · Niedrig: Warenkörbe treffen selten dieselbe Zeile · Optimistisches Versionsfeld · Ein Lock für das Checkout-Fenster kostet mehr als die seltene Wiederholung

• Einreichen eines Prüfungsversuchs (PS Classes) · Einmalig pro Versuch · Redis-Lock auf der Versuch-ID · Eine Einreichung erfolgt einmal, daher sind wenige Millisekunden Lock günstiger als eine korrupte Rangfolge

Ursprünglich veröffentlicht auf sakshamjain.codes/blog/optimistic-vs-pessimistic-locking. Benötigen Sie eine Umsetzung? Sehen Sie meine Services auf NexoRush oder kontaktieren Sie mich.