Nachrichtenwarteschlangen
Mechanismus zur asynchronen Kommunikation zwischen Komponenten durch Zwischenspeicherung und geordnete Zustellung von Nachrichten.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Nachrichtenverlust bei falscher Konfiguration
- Überlastung der Queue führt zu wachsender Latenz
- Ungenaue Zustellsemantik verursacht Inkonsistenzen
- Idempotente Konsumenten implementieren
- Dead-letter-Queues und Retries konfigurieren
- Metriken und Alerts für Warteschlangenlänge und Latenz einrichten
I/O & Ressourcen
- Produzierte Nachrichten/Ereignisse
- Nachrichtenformate und Schemas
- Authentifizierungs- und Autorisierungsdaten
- Verarbeitete Nachrichten durch Konsumenten
- Monitoring- und Metriken zur Beobachtbarkeit
- Fehler- und Dead-letter-Einträge
Beschreibung
Nachrichtenwarteschlangen sind architektonische Komponenten, die Produzenten und Konsumenten entkoppeln, indem sie Nachrichten zur asynchronen Zustellung zwischenspeichern. Sie ermöglichen Lastglättung, Fehlerresilienz und skalierbare ereignisgetriebene Integrationen zwischen Diensten. Architekturentscheidungen betreffen Persistenz, Backpressure, Wiederholung und SLA-Abgleich.
✔Vorteile
- Erhöhte Resilienz durch asynchrone Verarbeitung
- Bessere Lastverteilung und Skalierbarkeit
- Entkopplung erlaubt unabhängige Entwicklung
✖Limitationen
- Zusätzliche Infrastruktur und Betriebsaufwand
- Latenz durch Persistenz und Warteschlangenverarbeitung
- Komplexität bei Reihenfolge- und Transaktionsgarantien
Trade-offs
Metriken
- Warteschlangen-Länge
Anzahl unverarbeiteter Nachrichten pro Queue; Indikator für Backlog.
- Durchsatz (Nachrichten/s)
Anzahl verarbeiteter Nachrichten pro Sekunde; misst Kapazität.
- Zustellzeiten / Latenz
Zeit von Erzeugung bis Verarbeitung; wichtig für SLAs.
Beispiele & Implementierungen
RabbitMQ in Microservice-Architektur
Einsatz von RabbitMQ zur zuverlässigen Aufgabenverteilung und Kommandosynchronisation zwischen Services.
Kafka für Event-Streaming
Apache Kafka als verteilte Log-basierte Plattform für hohe Durchsatzraten und langlebige Eventspeicherung.
AWS SQS in serverlosen Flows
AWS SQS zur Entkopplung von Lambda-basierten Konsumenten und zur Lastglättung in Serverless-Architekturen.
Implementierungsschritte
Anforderungen an Durchsatz und Zustellgarantien ermitteln
Geeigneten Broker oder Managed-Service auswählen
Schema-Registry und Monitoring einführen, Konsumenten implementieren
⚠️ Technische Schulden & Engpässe
Tech Debt
- Kurzfristig implementierte Retry-Logik ohne Idempotenzprüfung
- Wachsende Abhängigkeit von proprietären Broker-Features
- Fehlende Schema-Versionierung für Nachrichten
Bekannte Engpässe
Beispiele für Missbrauch
- Verwenden einer Queue für unmittelbare Nutzerwartezeiten statt direkter Kommunikation
- Persistente Speicherung sensibler Daten in Nachrichten ohne Verschlüsselung
- Übermäßige Partitionierung ohne Konsistenzstrategie
Typische Fallen
- Unterdimensionierte Broker-Kapazität führt zu Backlogs
- Fehlende Observability erschwert Problemdiagnose
- Unklare Zustellsemantik zwischen Komponenten
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Maximale Nachrichten- oder Größenlimits des Brokers
- • SLA-Vorgaben für Zustellung und Latenz
- • Regulatorische Anforderungen an Persistenz und Datenschutz