Message Queue

Was ist eine Message Queue?

Eine Message Queue ist ein Puffer zwischen zwei Teilen eines Systems, damit sie nicht im selben Moment miteinander reden müssen. Ein Service legt eine Nachricht in die Queue, ein anderer holt sie heraus und verarbeitet sie, wenn er bereit ist. Der Sender wartet nicht, bis die Arbeit fertig ist. Er übergibt die Nachricht und macht weiter.

Das entkoppelt Timing und Last. Erzeugt ein Verkehrsstoß mehr Arbeit, als die Konsumenten bewältigen, fängt die Queue den Rückstau ab, statt das System zum Absturz zu bringen. Nachrichten warten in der Reihe und werden in stetigem Tempo verarbeitet. Eine Videoplattform, die jeden Upload transkodieren muss, kann jede Datei in eine Queue legen, dem Nutzer sofort antworten und einen Pool von Workern die Kodierung im Hintergrund abarbeiten lassen. Werkzeuge wie RabbitMQ, Amazon SQS und Redis-basierte Queues sind übliche Optionen.

Queues bringen auch Zuverlässigkeit. Eine Nachricht bleibt in der Queue, bis ein Konsument bestätigt, dass er sie bearbeitet hat, sodass ein mitten in der Aufgabe abstürzender Worker den Job nicht verliert. Eine Queue ist von einem log-basierten System wie Kafka zu unterscheiden. Eine klassische Queue liefert jede Nachricht an einen Konsumenten und entfernt sie nach der Verarbeitung, während ein Log einen geordneten Datensatz hält, den viele Konsumenten erneut abspielen können. Unterschiedliche Werkzeuge für unterschiedliche Problemformen.

Message Queues bei Dallonses

Wir fügen eine Message Queue hinzu, wenn ein System Arbeit hat, die den Nutzer nicht blockieren sollte. Ein Kunde mit einer Plattform unter hoher Last ließ Bildverarbeitung, Benachrichtigungen und Berichterstellung inline laufen, und bei Spitzenlast liefen die Anfragen in Timeouts. Wir verlagerten diese Arbeit hinter eine Queue. Die Antwort zum Nutzer fiel auf Millisekunden, und eine Reihe von Workern übernahm die Schwerarbeit in einem Tempo, das die Infrastruktur tragen konnte.

Queues sind ein Kernstück unseres Vorgehens bei Integrationsplattformen und API-Integration, denn die Systeme, die wir verbinden, laufen selten im gleichen Tempo. Wir entwerfen die Nachrichtenverträge, das Retry-Verhalten und die Dead-Letter-Behandlung so, dass ein fehlgeschlagener Job aufgefangen und erneut abgespielt wird, nicht still verloren geht. Das Ergebnis sind Systeme, die unter Last reaktionsfähig bleiben und weiterarbeiten, wenn ein Teil einen schlechten Tag hat.

Stapelt sich die Arbeit und läuft unter Last in Timeouts? Holen wir sie vom kritischen Pfad.

Sprechen Sie mit uns über Queues