Das Problem: Verteilte Transaktionen bei der Hotelbuchung

Teilen wir unser Hotelbuchungssystem in seine Kernkomponenten auf:

  • Reservierungsdienst: Verwaltet die Verfügbarkeit und Buchung von Zimmern
  • Zahlungsdienst: Bearbeitet Zahlungen
  • Benachrichtigungsdienst: Sendet Bestätigungs-E-Mails
  • Treueprogramm-Dienst: Aktualisiert Kundenpunkte

Stellen Sie sich nun ein Szenario vor, in dem ein Kunde ein Zimmer bucht. Wir müssen:

  1. Die Zimmerverfügbarkeit prüfen und reservieren
  2. Die Zahlung abwickeln
  3. Eine Bestätigungs-E-Mail senden
  4. Die Treuepunkte des Kunden aktualisieren

Klingt einfach, oder? Nicht so schnell. Was passiert, wenn die Zahlung fehlschlägt, nachdem wir das Zimmer reserviert haben? Oder wenn der Benachrichtigungsdienst ausfällt? Willkommen in der Welt der verteilten Transaktionen, wo Murphys Gesetz immer gilt.

Sagas: Die unbekannten Helden der verteilten Transaktionen

Eine Saga ist eine Abfolge von lokalen Transaktionen, bei denen jede Transaktion Daten innerhalb eines einzelnen Dienstes aktualisiert. Wenn ein Schritt fehlschlägt, führt die Saga ausgleichende Transaktionen aus, um die Änderungen der vorherigen Schritte rückgängig zu machen.

So könnte unsere Hotelbuchungs-Saga aussehen:


def book_hotel_room(customer_id, room_id, payment_info):
    try:
        # Schritt 1: Zimmer reservieren
        reservation_id = reservation_service.reserve_room(room_id)
        
        # Schritt 2: Zahlung abwickeln
        payment_id = payment_service.process_payment(payment_info)
        
        # Schritt 3: Bestätigung senden
        notification_service.send_confirmation(customer_id, reservation_id)
        
        # Schritt 4: Treuepunkte aktualisieren
        loyalty_service.update_points(customer_id, calculate_points(room_id))
        
        return "Buchung erfolgreich!"
    except Exception as e:
        # Wenn ein Schritt fehlschlägt, ausgleichende Maßnahmen ergreifen
        compensate_booking(reservation_id, payment_id, customer_id)
        raise e

def compensate_booking(reservation_id, payment_id, customer_id):
    if reservation_id:
        reservation_service.cancel_reservation(reservation_id)
    if payment_id:
        payment_service.refund_payment(payment_id)
    notification_service.send_cancellation(customer_id)
    # Keine Notwendigkeit, Treuepunkte auszugleichen, da sie noch nicht hinzugefügt wurden

Implementierung von Idempotenz: Weil einmal nicht immer genug ist

In verteilten Systemen können Netzwerkprobleme zu doppelten Anfragen führen. Um dies zu handhaben, müssen wir unsere Operationen idempotent machen. Hier kommen Idempotenzschlüssel ins Spiel:


def reserve_room(room_id, idempotency_key):
    if reservation_exists(idempotency_key):
        return get_existing_reservation(idempotency_key)
    
    # Tatsächliche Reservierungslogik ausführen
    reservation = create_reservation(room_id)
    store_reservation(idempotency_key, reservation)
    return reservation

Durch die Verwendung eines Idempotenzschlüssels (typischerweise eine vom Client generierte UUID) stellen wir sicher, dass selbst wenn dieselbe Anfrage mehrmals gesendet wird, nur eine Reservierung erstellt wird.

Asynchrone Rollbacks: Weil die Zeit auf keine Transaktion wartet

Manchmal können ausgleichende Maßnahmen nicht sofort ausgeführt werden. Wenn zum Beispiel der Zahlungsdienst vorübergehend ausfällt, können wir nicht sofort eine Rückerstattung vornehmen. Hier kommen asynchrone Rollbacks ins Spiel:


def compensate_booking_async(reservation_id, payment_id, customer_id):
    compensation_tasks = [
        {'service': 'reservation', 'action': 'cancel', 'id': reservation_id},
        {'service': 'payment', 'action': 'refund', 'id': payment_id},
        {'service': 'notification', 'action': 'send_cancellation', 'id': customer_id}
    ]
    
    for task in compensation_tasks:
        compensation_queue.enqueue(task)

# In einem separaten Worker-Prozess
def process_compensation_queue():
    while True:
        task = compensation_queue.dequeue()
        try:
            execute_compensation(task)
        except Exception:
            # Wenn die Kompensation fehlschlägt, erneut in die Warteschlange einreihen mit exponentiellem Backoff
            compensation_queue.requeue(task, delay=calculate_backoff(task))

Dieser Ansatz ermöglicht es uns, Kompensationen zuverlässig zu handhaben, selbst wenn Dienste vorübergehend nicht verfügbar sind.

Die Fallstricke: Was könnte schiefgehen?

Obwohl Sagas mächtig sind, sind sie nicht ohne Herausforderungen:

  • Komplexität: Die Implementierung von ausgleichenden Maßnahmen für jeden Schritt kann knifflig sein.
  • Eventuelle Konsistenz: Es gibt ein Zeitfenster, in dem das System in einem inkonsistenten Zustand ist.
  • Fehlende Isolation: Andere Transaktionen könnten Zwischenzustände sehen.

Um diese Probleme zu mildern:

  • Verwenden Sie einen Saga-Orchestrator, um den Workflow und die Kompensationen zu verwalten.
  • Implementieren Sie robuste Fehlerbehandlung und Protokollierung.
  • Erwägen Sie die Verwendung von pessimistischem Sperren für kritische Ressourcen.

Der Nutzen: Warum sich die Mühe machen?

Sie denken vielleicht: "Das scheint viel Arbeit zu sein. Warum nicht einfach 2PC verwenden?" Hier ist der Grund:

  • Skalierbarkeit: Sagas erfordern keine langanhaltenden Sperren, was eine bessere Skalierbarkeit ermöglicht.
  • Flexibilität: Dienste können unabhängig aktualisiert werden, ohne die gesamte Transaktion zu unterbrechen.
  • Resilienz: Das System kann weiter funktionieren, selbst wenn einige Dienste vorübergehend ausfallen.
  • Leistung: Keine Notwendigkeit für verteilte Sperren bedeutet schnellere Transaktionsverarbeitung insgesamt.

Zusammenfassung: Die wichtigsten Erkenntnisse

Die Implementierung verteilter Transaktionen ohne 2PC unter Verwendung von ausgleichenden Workflows und Sagas bietet eine robuste und skalierbare Lösung für komplexe Systeme wie Hotelbuchungsplattformen. Durch die Nutzung von Idempotenzschlüsseln und asynchronen Rollbacks können wir widerstandsfähige Systeme aufbauen, die Ausfälle elegant handhaben und Datenkonsistenz über Microservices hinweg sicherstellen.

Denken Sie daran, das Ziel ist nicht, Ausfälle zu vermeiden (sie sind in verteilten Systemen unvermeidlich), sondern sie elegant zu handhaben. Mit Sagas buchen wir nicht nur Hotelzimmer; wir betreten eine Welt zuverlässigerer und skalierbarer verteilter Transaktionen.

"In verteilten Systemen sind Ausfälle nicht nur möglich, sie sind unvermeidlich. Entwerfen Sie für den Ausfall, und Sie werden für den Erfolg bauen."

Nun, gehen Sie voran und mögen Ihre Transaktionen immer zu Ihren Gunsten sein!

Weiterführende Literatur

Viel Spaß beim Programmieren, und mögen Ihre verteilten Transaktionen immer reibungslos und ausgeglichen sein!