Race-Proof Cron Sweep: Dienste sicher sperren

Wenn die Zahlung eines Kunden fehlschlägt, muss Ihre Automatisierung seinen Dienst sperren. Aber wenn Ihr Cron-Job läuft, während ein anderer Prozess dieselben Datensätze aktualisiert, riskieren Sie, einen Kunden zu sperren, der gerade bezahlt hat, oder einen zu übersehen, der nicht bezahlt hat. Diese Race Condition kann Sie Umsatz und Vertrauen kosten. Hier ist, wie Sie einen Sweep entwerfen, der nur die richtigen Zeilen berührt, jedes Mal.

Warum benötigen Cron-Sweeps für Zahlungsfehler Race-Condition-Schutz?

Race Conditions treten auf, wenn zwei Prozesse gleichzeitig dieselben Daten lesen und schreiben. Bei der Abrechnung ist ein häufiges Szenario ein Cron-Job, der nach überfälligen Rechnungen sucht und Dienste sperrt, während ein Webhook von einem Zahlungsgateway eine Rechnung als bezahlt markiert. Wenn der Cron die Rechnung kurz bevor der Webhook sie aktualisiert als unbezahlt liest, könnte er einen Kunden sperren, der tatsächlich bezahlt hat. Dies führt zu verärgerten Kunden und Support-Tickets.

Um dies zu vermeiden, müssen Sie Ihr Abfragemuster so gestalten, dass die Prüfung und die Aktion atomar sind oder zumindest vor gleichzeitigen Änderungen geschützt sind.

Was ist das Kernmuster für einen Race-Condition-sicheren Sweep?

Die Grundidee besteht darin, eine bedingte Aktualisierung zu verwenden, die nur Zeilen in einem bestimmten Zustand betrifft, und die Zeile zu beanspruchen, bevor Sie darauf reagieren. In SQL können Sie dies mit einem UPDATE ... WHERE status = 'overdue' tun, das einen Status wie 'suspending' setzt und die betroffenen Zeilen zurückgibt. Auf diese Weise kann jeweils nur ein Prozess eine Zeile beanspruchen, da die Aktualisierung den Status ändert und andere Prozesse sie nicht mehr als 'overdue' sehen.

Zum Beispiel, anstatt:

SELECT * FROM services WHERE payment_status = 'overdue';
-- dann jeden Dienst sperren

tun Sie:

UPDATE services SET status = 'suspending' WHERE payment_status = 'overdue' AND status = 'active' RETURNING id;

Diese Aktualisierung beansprucht die Zeilen atomar. Nur die aktualisierten Zeilen werden zurückgegeben, und sie befinden sich jetzt in einem Zustand, der verhindert, dass andere Prozesse sie erneut beanspruchen.

Wie handhaben Sie die eigentliche Sperrung nach dem Beanspruchen der Zeilen?

Nachdem Sie die Zeilen beansprucht haben, führen Sie die Sperraktion aus, z. B. indem Sie Ihre Provisioning-API aufrufen, um den Dienst zu stoppen. Aber was, wenn die Sperrung fehlschlägt? Sie benötigen eine Möglichkeit zum Wiederholen oder Zurücksetzen. Ein Ansatz ist ein Zähler für 'suspension_attempts' und einen Zeitstempel für 'next_retry_at'. Wenn die Sperrung fehlschlägt, erhöhen Sie den Zähler und setzen eine Wiederholungszeit. Wenn sie erfolgreich ist, setzen Sie den Status auf 'suspended'.

Wenn der Prozess nach dem Beanspruchen, aber vor dem Sperren abstürzt, benötigen Sie ein Timeout. Legen Sie beispielsweise einen Zeitstempel 'claimed_at' fest und suchen Sie in Ihrem Sweep auch nach Zeilen, die den Status 'suspending' haben, aber seit mehr als ein paar Minuten beansprucht sind. Diese können erneut versucht oder auf 'overdue' zurückgesetzt werden.

Was sind die häufigsten Fallstricke bei diesem Muster?

Ein Fallstrick ist die Verwendung einer separaten SELECT- und dann UPDATE-Anweisung, was die Atomarität bricht. Ein anderer ist die unsachgemäße Verwendung von Transaktionen. Wenn Sie eine Transaktion verwenden, müssen Sie sicherstellen, dass die Isolationsstufe angemessen ist. Für die meisten Datenbanken ist die Standardeinstellung in Ordnung, wenn Sie die bedingte Aktualisierung verwenden.

Ein weiterer Fallstrick ist, nicht alle relevanten Bedingungen in die WHERE-Klausel aufzunehmen. Wenn Sie beispielsweise nur den Zahlungsstatus prüfen, aber ein Kunde mehrere Dienste haben könnte, könnten Sie einen Dienst sperren, der nicht der mit der überfälligen Rechnung ist. Sie müssen mit der Rechnungs- oder Bestelltabelle verknüpfen, um sicherzustellen, dass Sie den richtigen Dienst sperren.

Wie testen Sie auf Race Conditions in Ihrem Sweep?

Tests sind entscheidend. Sie können Integrationstests schreiben, die gleichzeitige Aktualisierungen simulieren. Sie können beispielsweise einen Test haben, der eine Transaktion startet, die eine Zeile beansprucht, dann versucht, sie von einer anderen Verbindung erneut zu beanspruchen, und bestätigt, dass die zweite Beanspruchung keine Zeilen zurückgibt. Sie können auch Tools wie pgbench für PostgreSQL oder sysbench für MySQL verwenden, um Last zu simulieren.

Ein einfacherer Ansatz ist jedoch, einen Test zu schreiben, der die Sweep-Funktion ausführt und gleichzeitig eine Zeile von einer anderen Verbindung auf 'paid' aktualisiert, und dann überprüft, dass der Dienst nicht gesperrt wurde. Dies kann mit einem Skript erfolgen, das beide Operationen parallel ausführt.

Was sind die besten Praktiken für die Planung des Cron-Sweeps?

Planen Sie den Sweep zu einer Zeit, in der Ihr System am wenigsten ausgelastet ist, aber berücksichtigen Sie auch den Abrechnungszyklus. Wenn Sie beispielsweise Rechnungen am 1. senden, könnten Sie den Sweep am 5. ausführen, um Kunden eine Gnadenfrist zu geben. Verwenden Sie einen Cron-Ausdruck, der alle paar Minuten läuft, aber stellen Sie sicher, dass der Sweep idempotent ist, d. h. er kann mehrfach ausgeführt werden, ohne Schaden zu verursachen.

Erwägen Sie auch die Verwendung einer verteilten Sperre, wenn Sie mehrere Anwendungsserver haben. Sie möchten nicht, dass zwei Server denselben Sweep gleichzeitig ausführen. Tools wie Redis oder datenbankbasierte Sperren können helfen.

Wie handhabt Teculiar dies?

Teculiar, eine Plattform für Hosting- und Domain-Reseller, integriert diese Muster in seine Abrechnungsautomatisierung. Wenn Sie die Automatisierungsfunktionen von Teculiar verwenden, können Sie darauf vertrauen, dass die Sperrlogik Race-Condition-sicher ist. Wenn Sie jedoch Ihre eigene erstellen, befolgen Sie die obigen Muster.

Für fortgeschrittenere Szenarien möchten Sie möglicherweise ein Warteschlangensystem verwenden, bei dem Sie Sperraufgaben in die Warteschlange stellen und Worker sie verarbeiten, aber das Kernprinzip bleibt: Beanspruchen Sie die Zeile atomar, bevor Sie handeln.

Was als Nächstes zu tun ist

• Überprüfen Sie Ihre aktuellen Sweep-Abfragen und identifizieren Sie alle, die separate SELECT- und UPDATE-Anweisungen verwenden.
• Schreiben Sie sie mit bedingtem UPDATE ... RETURNING um, um Zeilen atomar zu beanspruchen.
• Fügen Sie einen Wiederholungsmechanismus mit einem Zähler und Timeout für fehlgeschlagene Sperrungen hinzu.
• Schreiben Sie Tests, die gleichzeitigen Zugriff simulieren, um sicherzustellen, dass Ihr Sweep sicher ist.

Sobald Sie ein solides Muster haben, können Sie es auf andere Automatisierungsaufgaben wie Domain-Ablaufprüfungen oder Ressourcenüberschreitungsabrechnungen anwenden.