Was ist eine Message Queue? Hintergrundjobs mit RabbitMQ

Eine Message Queue (Nachrichtenwarteschlange) ist eine Zwischenschicht, in der eine Anwendung eine Aufgabe als Nachricht ablegt, statt sie sofort auszuführen, und ein anderer Prozess diese Nachrichten der Reihe nach abholt und verarbeitet. Kurz gesagt: Sie trennt Arbeit, die den Nutzer nicht warten lassen soll oder von einem externen System abhängt (E-Mail, Rechnungsstellung, Benachrichtigungen, Berichte), vom Web-Request; wird das externe System langsam oder fällt aus, geht die Aufgabe nicht verloren, sondern wartet in der Queue. RabbitMQ ist eines der verbreitetsten Open-Source-Werkzeuge dafür.

Was ist eine Message Queue und wie funktioniert sie?

Das Modell hat drei Teile. Der Producer sendet eine kleine Nachricht, die die Arbeit beschreibt, etwa "Rechnung für Bestellung 42 erstellen". Der Broker, hier RabbitMQ, speichert die Nachricht dauerhaft. Der Consumer ist ein eigener Worker-Prozess; er holt die Nachricht, erledigt die Arbeit und bestätigt sie (ack). Stürzt der Worker vor der Bestätigung ab, gibt der Broker die Nachricht an einen anderen Worker. So speichert der Webserver die Bestellung und antwortet sofort, während die Rechnung wenige Sekunden später im Hintergrund entsteht.

Wofür wird eine Message Queue eingesetzt?

• E-Mail- und SMS-Versand: Registrierung und Checkout warten nicht, auch wenn der Anbieter langsam ist.
• Rechnungen und behördliche Schnittstellen: Bei externen Diensten mit verzögerter Antwort, etwa der E-Rechnungs-Integration, übernimmt die Queue die Wiederholungen.
• Eingehende Webhook-Ereignisse: Das Ereignis wird sofort angenommen und eingereiht, die Verarbeitung erfolgt getrennt; Details in Was ist ein Webhook.
• Aufwendige Arbeit: PDF- und Berichtserzeugung, Bildskalierung, Massenimporte.
• Kommunikation zwischen Diensten: wenn mehrere Dienste auf ein Ereignis in einem Dienst reagieren müssen.

Eine Queue sorgt dafür, dass keine Arbeit verloren geht, aber nicht dafür, dass sie nur einmal erledigt wird. Dieselbe Nachricht kann mehrfach ankommen, daher muss jeder Consumer idempotent sein: Erhält er dieselbe Aufgabe ein zweites Mal, darf sich das Ergebnis nicht ändern.

Bestätigung, Wiederholung und Dead Letter Queue

Ein solides Setup trifft drei Entscheidungen von Anfang an. Erstens die Bestätigung: Der Consumer bestätigt erst, wenn die Arbeit wirklich erledigt ist, nicht beim Empfang. Zweitens Wiederholungen: Bei vorübergehenden Fehlern wird die Nachricht begrenzt oft mit Verzögerung erneut versucht, nie in einer Endlosschleife. Drittens die Dead Letter Queue: Eine Nachricht ohne verbleibende Versuche landet in einer eigenen Queue, wird dort überwacht und nach Behebung der Ursache manuell erneut gesendet. Die Zahl der dort angesammelten Nachrichten muss überwacht werden und ab einem Schwellenwert einen Alarm auslösen.

Das Node.js-Beispiel zeigt einen Producer, der nach einer Bestellung die Rechnung einreiht, und einen Consumer, der sie verarbeitet. Die Nachrichten-ID ist die Bestellnummer; die Funktion createInvoiceOnce im Consumer erstellt für dieselbe Bestellung nie eine zweite Rechnung.

import amqp from 'amqplib';

const conn = await amqp.connect(process.env.AMQP_URL ?? 'amqp://localhost');
const ch = await conn.createChannel();
await ch.assertQueue('invoices', { durable: true });

// Producer: the web request only drops a message and returns.
export function enqueueInvoice(orderId: string) {
  ch.sendToQueue('invoices', Buffer.from(JSON.stringify({ orderId })), {
    persistent: true,
    messageId: orderId, // used for idempotency on the consumer side
  });
}

// Consumer: a separate worker process.
await ch.prefetch(5);
await ch.consume('invoices', async (msg) => {
  if (!msg) return;
  const { orderId } = JSON.parse(msg.content.toString());
  try {
    await createInvoiceOnce(orderId); // safe to run twice for the same order
    ch.ack(msg);
  } catch {
    ch.nack(msg, false, false); // goes to the dead letter queue
  }
});

RabbitMQ, Redis oder Kafka?

RabbitMQ ist für klassische Job-Queues gebaut: Routing, Bestätigungen, Prioritäten und Dead Letter Queues sind eingebaut. Läuft in der Anwendung bereits Redis, können Redis-basierte Queue-Bibliotheken für Hintergrundjobs mit geringem Volumen reichen; zu weiteren Einsätzen siehe unseren Beitrag Was ist Redis. Kafka ist ein Ereignisprotokoll, das Nachrichten lange aufbewahrt; es lohnt sich bei großen Ereignisströmen und wenn dieselben Daten später erneut gelesen werden müssen, für eine einfache Job-Queue ist es überdimensioniert. Entscheidend sind die Aufbewahrungsdauer und die Zahl der Leser, nicht die Popularität des Werkzeugs.

Wann ist eine Message Queue überflüssig?

Nicht jeder Hintergrundjob braucht eine Queue. Für Berichte oder Aufräumarbeiten zu festen Zeiten ist ein geplanter Job (Cronjob) einfacher. In einer Anwendung mit wenig Verkehr auf einem Server genügt oft eine Tabelle "offene Jobs" in der Datenbank und ein kleiner Worker, der sie liest. Eine Queue ist eine weitere Komponente, die überwacht, gesichert und aktualisiert werden muss. Aus demselben Grund lohnt es sich, die Frage Microservices oder Monolith zu klären, bevor man die Anwendung in Dienste aufteilt.

Fazit

Eine Message Queue verlagert Arbeit, die Nutzer nicht warten lassen soll oder von externen Systemen abhängt, sicher in den Hintergrund. Ihren Wert zeigt sie, wenn Bestätigung, begrenzte Wiederholungen, Dead Letter Queue und idempotente Consumer zusammen eingerichtet werden. Wenn Sie die Hintergrundverarbeitung Ihres Projekts gemeinsam planen möchten, sehen Sie sich unsere Seite Individualsoftware an oder schreiben Sie uns über das Formular Angebot anfordern.