Erstellen eines skalierbaren SQS-Verbrauchers in Go

Einführung

Beim Aufbau verteilter Systeme spielen Nachrichtenwarteschlangen wie Amazon SQS eine entscheidende Rolle bei der Bewältigung asynchroner Arbeitslasten. In diesem Beitrag teile ich meine Erfahrungen bei der Implementierung eines robusten SQS-Consumers in Go, der Benutzerregistrierungsereignisse für Keycloak verarbeitet. Die Lösung nutzt das Fan-Out/Fan-In-Parallelitätsmuster, um Nachrichten effizient zu verarbeiten, ohne die Systemressourcen zu überlasten.

Die Herausforderung

Ich stand vor einem interessanten Problem: Verarbeiten Sie täglich etwa 50.000 SQS-Ereignisse, um Benutzer in Keycloak zu registrieren. Ein naiver Ansatz könnte für jede Nachricht eine neue Goroutine erzeugen, aber dies könnte schnell zur Erschöpfung der Ressourcen führen. Wir brauchten einen kontrollierteren Ansatz für die Parallelität.

Warum Fan-out/Fan-in?

Das Fan-Out/Fan-In-Muster ist für diesen Anwendungsfall perfekt, weil es:

• Verwaltet einen festen Pool von Worker-Goroutinen
• Verteilt die Arbeit gleichmäßig auf die Mitarbeiter
• Verhindert die Erschöpfung der Ressourcen
• Bietet eine bessere Kontrolle über gleichzeitige Vorgänge

Tiefer Einblick in die Implementierung

1. Die Verbraucherstruktur

Schauen wir uns zunächst unsere grundlegende Verbraucherstruktur an:

type Consumer struct {
    Client    *sqs.Client
    QueueName string
}

2. Nachrichtenverarbeitungspipeline

Die Implementierung besteht aus drei Hauptkomponenten:

1. Nachrichtenempfänger: Fragt SQS kontinuierlich nach neuen Nachrichten ab
2. Worker-Pool: Anzahl der Goroutinen, die Nachrichten verarbeiten, wurde korrigiert
3. Nachrichtenkanal: Verbindet den Empfänger mit den Mitarbeitern

So starten wir den Verbraucher:

func StartPool[requestBody any](
    serviceFunc func(c context.Context, dto *requestBody) error,
    consumer *Consumer) {

    ctx := context.Background()
    params := &sqs.ReceiveMessageInput{
        MaxNumberOfMessages: 10,
        QueueUrl:           aws.String(consumer.QueueName),
        WaitTimeSeconds:    20,
        VisibilityTimeout:  30,
        MessageAttributeNames: []string{
            string(types.QueueAttributeNameAll),
        },
    }

    msgCh := make(chan types.Message)
    var wg sync.WaitGroup

    // Start worker pool first
    startPool(ctx, msgCh, &wg, consumer, serviceFunc)

    // Then start receiving messages
    // ... rest of the implementation
}

3. Wichtige Konfigurationsparameter

Lassen Sie uns die entscheidenden SQS-Konfigurationsparameter untersuchen:

• MaxNumberOfMessages (10): Stapelgröße für jede Umfrage
• WaitTimeSeconds (20): Lange Abfragedauer
• VisibilityTimeout (30): Kulanzzeitraum für die Nachrichtenverarbeitung

4. Implementierung des Worker-Pools

Im Worker-Pool kommt das Fan-out-Muster ins Spiel:

func startPool[requestBody any](
    ctx context.Context,
    msgCh chan types.Message,
    wg *sync.WaitGroup,
    consumer *Consumer,
    serviceFunc func(c context.Context, dto *requestBody) error) {

    processingMessages := &sync.Map{}

    // Start 10 workers
    for i := 0; i 



<h3>
  
  
  5. Umgang mit doppelten Nachrichten
</h3>

<p>Wir verwenden eine sync.Map, um die Verarbeitung doppelter Nachrichten zu verhindern:<br>
</p><pre class="brush:php;toolbar:false">type Consumer struct {
    Client    *sqs.Client
    QueueName string
}

Best Practices und Erkenntnisse

1. Fehlerbehandlung: Behandeln Sie Fehler immer ordnungsgemäß und protokollieren Sie sie ordnungsgemäß
2. Nachrichtenbereinigung: Nachrichten erst nach erfolgreicher Verarbeitung löschen
3. Graceful Shutdown: Implementieren Sie geeignete Abschaltmechanismen mithilfe des Kontexts
4. Überwachung: Fügen Sie zur Beobachtbarkeit Protokollierung an wichtigen Punkten hinzu

Leistungsüberlegungen

• Anzahl der Mitarbeiter: Wählen Sie basierend auf Ihrer Arbeitsbelastung und den verfügbaren Ressourcen
• Chargengröße: Gleichgewicht zwischen Durchsatz und Verarbeitungszeit
• Sichtbarkeits-Timeout: Stellen Sie es entsprechend Ihrer durchschnittlichen Verarbeitungszeit ein

Zukünftige Verbesserungen

1. Dynamische Worker-Skalierung: Passen Sie die Worker-Anzahl basierend auf der Warteschlangentiefe an
2. Leistungsschalter: Leistungsschalter für nachgelagerte Dienste hinzufügen
3. Metriksammlung: Fügen Sie Prometheus-Metriken zur Überwachung hinzu
4. Warteschlange für nicht zustellbare Nachrichten: Implementieren Sie die DLQ-Behandlung für fehlgeschlagene Nachrichten
5. Wiederholungen: Exponentielles Backoff für vorübergehende Fehler hinzufügen

Abschluss

Das Fan-Out/Fan-In-Muster bietet eine elegante Lösung für die Verarbeitung großer SQS-Nachrichten in Go. Durch die Aufrechterhaltung eines festen Worker-Pools vermeiden wir die Fallstricke einer unbegrenzten Goroutine-Erstellung und stellen gleichzeitig eine effiziente Nachrichtenverarbeitung sicher.

Denken Sie daran, bei der Implementierung solcher Muster immer Ihren spezifischen Anwendungsfall zu berücksichtigen. Die hier angezeigten Konfigurationswerte (Worker-Anzahl, Timeout-Werte usw.) sollten basierend auf Ihren Anforderungen und Ressourcenbeschränkungen angepasst werden.

---

Quellcode: [Link zu Ihrem Repository, falls verfügbar]

Tags: #golang #aws #sqs #concurrency #distributed-systems

Das obige ist der detaillierte Inhalt vonErstellen eines skalierbaren SQS-Verbrauchers in Go. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!