Building Kafka Consumers

Was macht Building Kafka Consumers?

Wann verwenden

• Schreiben oder Debuggen von Kafka-Consumern/-Producern.
• Auswahl der Offset-Commit-Strategie und Liefergarantien.
• Optimieren der Consumer-Group-Parallelität, Rebalancing oder Dead-Letter-Behandlung.
• NICHT verwenden für Stream-Processing/Fensterung (verwende processing-streaming-data).

Arbeitsablauf

- [ ] Partitionen dimensionieren, um die gewünschte Parallelität zu erreichen (Consumer ≤ Partitionen)
- [ ] Offsets NACH erfolgreicher Verarbeitung committen
- [ ] Die Senke idempotent machen (Upsert per Event-Key)
- [ ] Rebalancing behandeln (Commit bei Revoke, lange Poll-Pausen vermeiden)
- [ ] Gift-Nachrichten an ein Dead-Letter-Topic weiterleiten

1. Partitionen begrenzen die Parallelität. Eine Consumer-Group skaliert nur bis zur Anzahl der Partitionen; zusätzliche Consumer bleiben untätig. Wähle Partitionen für den Spitzendurchsatz.
2. Nach der Verarbeitung committen. Committe Offsets erst, wenn die Arbeit dauerhaft erledigt ist, nicht vorher – frühzeitiges Committen führt bei einem Absturz zu Nachrichtenverlust.
3. Idempotente Senke. At-Least-Once bedeutet Duplikate bei Wiederholungen; Upsert mit einem stabilen Event-Key macht die erneute Verarbeitung unschädlich.
4. Rebalancing tritt auf. Committe bei Partitions-Revoke und halte poll()-Intervalle unter max.poll.interval.ms, damit der Broker den Consumer nicht ausschließt.
5. Gift-Nachrichten werden an ein Dead-Letter-Topic mit dem Fehler gesendet, sodass eine fehlerhafte Nachricht nicht die gesamte Partition blockiert.

Patterns

Manuelles Committen nach der Verarbeitung:

consumer = KafkaConsumer("orders", group_id="etl",
                         enable_auto_commit=False,
                         max_poll_records=500)
for msg in consumer:
    try:
        upsert(process(msg))          # idempotent per Key
        consumer.commit()             # nur bei Erfolg committen
    except PoisonError:
        send_to_dlq(msg)
        consumer.commit()             # fehlerhafte Nachricht überspringen

Idempotenter / transaktionaler Producer – setze enable.idempotence=true (dedupliziert Wiederholungen) und verwende Transaktionen für Read-Process-Write Exactly-Once über Topics hinweg.

Durchsatzoptimierung – erhöhe max.poll.records, fetch.min.bytes und verarbeite in Batches; halte die Verarbeitung schnell, um Rebalancing-Ausschluss zu vermeiden.

Häufige Fallstricke

• Auto-Commit + langsame Verarbeitung – Offsets werden fortgeschrieben, bevor die Arbeit abgeschlossen ist; ein Absturz verliert Nachrichten. Bevorzuge manuelles Committen nach der Verarbeitung.
• Mehr Consumer als Partitionen – die zusätzlichen bleiben untätig; partitioniere neu, um zu skalieren.
• Lange Verarbeitungszeit zwischen Polls – überschreitet max.poll.interval.ms und löst endlose Rebalancings aus; verarbeite in begrenzten Batches oder verwende einen Hintergrund-Worker.
• Kein Dead-Letter-Pfad – eine Gift-Nachricht blockiert die gesamte Partition.
• Auf Exactly-Once ohne idempotente Senke verlassen – jeder At-Least-Once-Schritt führt Duplikate wieder ein.