Point to Point Channel: Einen Auftrag an jeweils einen Empfänger verteilen

Nachrichten und Ereignisse

Point to Point Channel

Einen Auftrag an jeweils einen Empfänger verteilen

Die Idee und ihr Nutzen

Der Schadendienst einer Versicherung, also das Programm für die Bearbeitung von Schäden, legt Zahlungsaufträge in eine Warteschlange. Eine Warteschlange ist ein Zwischenspeicher, in dem Aufträge der Reihe nach warten, bis ein Empfänger sie abholt. Zwei Instanzen des Zahlungsdienstes holen die Aufträge dort ab und teilen sich die Arbeit. Der Zahlungsdienst ist das Programm, das die Überweisungen veranlasst, und eine Instanz ist ein laufendes Exemplar dieses Programms. Die Warteschlange gibt jeden Auftrag zunächst nur einer der beiden Instanzen. Stürzt diese Instanz ab, bevor sie die Erledigung bestätigt hat, gibt die Warteschlange denselben Auftrag später der anderen Instanz. Eine Warteschlange, die jeden Auftrag bei jedem Zustellversuch genau einem Empfänger gibt, heißt Point to Point Channel, auf Deutsch Punkt-zu-Punkt-Kanal.

Bausteine: Schadendienst: legt den Zahlungsauftrag ab; Warteschlange „zahlungen“: gibt jeden Auftrag genau einer Kopie; Zahlungsdienst Kopie 1: teilt sich die Arbeit mit Kopie 2; Zahlungsdienst Kopie 2: teilt sich die Arbeit mit Kopie 1. Verbindungen: Schadendienst → Warteschlange „zahlungen“; Warteschlange „zahlungen“ → Zahlungsdienst Kopie 1; Warteschlange „zahlungen“ → Zahlungsdienst Kopie 2. Die Warteschlange „zahlungen“ gibt jeden Zahlungsauftrag bei jedem Zustellversuch genau einer Instanz des Zahlungsdienstes.

Wie funktioniert es?

Der Schadendienst legt den Auftrag „1.200 € an 88123“ mit der Kennung zahl-4711-01 in die Warteschlange zahlungen. Der Auftrag lautet, dem Kunden mit der Nummer 88123 1.200 Euro zu überweisen. Die Warteschlange gibt den Auftrag an Kopie 2, die zweite Instanz des Zahlungsdienstes, und blendet ihn für alle anderen Empfänger aus. Die zweite Instanz beginnt mit der Arbeit, wird aber neu gestartet, bevor sie die Erledigung bestätigen kann. Weil keine Bestätigung kommt, gibt die Warteschlange den Auftrag nach Ablauf einer festgelegten Zeit wieder frei. Diese Zeit heißt Zustellfrist. Danach stellt die Warteschlange den Auftrag mit derselben Kennung zahl-4711-01 Kopie 1 zu, der ersten Instanz des Zahlungsdienstes. Die erste Instanz kann nicht erkennen, wie weit die zweite Instanz gekommen ist. Vielleicht hat die zweite Instanz die Überweisung schon an die Bank gegeben und im Zahlungsregister erfasst und wurde erst danach neu gestartet. Deshalb fragt die erste Instanz zuerst das Zahlungsregister, ob dort für zahl-4711-01 schon eine Zahlung erfasst ist. Das Zahlungsregister verzeichnet jede erfasste Zahlung mit der Kennung ihres Auftrags. Es antwortet „nein“. Erst dann gibt die erste Instanz die Überweisung über 1.200 Euro an die Bank. Danach erfasst die erste Instanz die Zahlung im Zahlungsregister unter der Kennung zahl-4711-01 und bestätigt der Warteschlange die Erledigung. Nach dieser Bestätigung löscht die Warteschlange den Auftrag.

Schadendienst und Zahlungsdienst tauschen ihre Daten nicht direkt miteinander aus, sondern über eine Nachrichtenplattform, ein eigenes Programm für den Austausch von Nachrichten. Die Nachrichtenplattform stellt die Warteschlange zahlungen bereit. Der Schadendienst ist der Sender: Er legt jeden Zahlungsauftrag in der Warteschlange ab und gibt ihm dabei eine eindeutige Kennung mit. Die Instanzen des Zahlungsdienstes sind die Empfänger: Sie holen die Aufträge ab. Die Warteschlange gibt jeden Auftrag bei einem Zustellversuch an genau einen Empfänger und bietet ihn keinem anderen Empfänger an, bis der erste Empfänger die Erledigung bestätigt oder die Zustellfrist abläuft. Je nach Nachrichtenplattform merkt sich die Warteschlange, an welchen Empfänger der Auftrag gegangen ist, oder sie blendet den Auftrag für die Dauer der Zustellfrist für alle anderen Empfänger aus. Wie lang die Zustellfrist ist, hängt von der Nachrichtenplattform und ihrer Einstellung ab.

„Genau ein Empfänger“ gilt für den einzelnen Zustellversuch, nicht für die gesamte Verarbeitung. Die Warteschlange sichert also nicht zu, dass der Kunde 88123 die 1.200 Euro nur einmal überwiesen bekommt. Das übernimmt der Empfänger: Er prüft vor der Ausführung anhand der Kennung, ob der Auftrag schon erledigt wurde. Hätte das Zahlungsregister zu zahl-4711-01 eine Zahlung gemeldet, hätte die erste Instanz der Warteschlange nur die Erledigung bestätigt und nicht erneut überwiesen. Dauert die Bearbeitung eines Auftrags länger als die Zustellfrist, muss der Empfänger die Frist rechtzeitig verlängern. Ein weiterer Zahlungsauftrag, etwa für einen anderen Schaden, ist ein eigener Zustellvorgang und kann an jede der beiden Instanzen gehen.

Beteiligte: Schadendienst: Sender des Zahlungsauftrags; Warteschlange „zahlungen“: gibt jeden Auftrag an genau einen Empfänger; Zahlungsdienst Kopie 1: Empfänger; Zahlungsdienst Kopie 2: Empfänger; Zahlungsregister: erfasste Zahlungen je Kennung; Bank: führt Überweisungen aus. Ablauf: 1. Der Schadendienst legt den Auftrag „1.200 € an 88123“ mit der Kennung zahl-4711-01 in die Warteschlange zahlungen. 2. Die Warteschlange zahlungen gibt den Auftrag an Kopie 2, die zweite Instanz des Zahlungsdienstes, und blendet ihn für alle anderen Empfänger aus. 3. Die zweite Instanz des Zahlungsdienstes beginnt mit der Arbeit, wird aber neu gestartet, bevor sie die Erledigung bestätigen kann. 4. Weil keine Bestätigung kommt, gibt die Warteschlange zahlungen den Auftrag nach Ablauf der Zustellfrist wieder frei. 5. Kopie 1, die erste Instanz des Zahlungsdienstes, erhält denselben Auftrag mit derselben Kennung zahl-4711-01. 6. Die erste Instanz des Zahlungsdienstes kann nicht erkennen, wie weit die zweite Instanz gekommen ist, und fragt deshalb das Zahlungsregister, ob dort für zahl-4711-01 schon eine Zahlung erfasst ist. 7. Das Zahlungsregister antwortet „nein“. Hätte das Zahlungsregister eine Zahlung gemeldet, hätte die erste Instanz nur die Erledigung bestätigt und nicht erneut überwiesen. 8. Die erste Instanz des Zahlungsdienstes gibt die Überweisung über 1.200 Euro an die Bank und erfasst die Zahlung im Zahlungsregister unter der Kennung zahl-4711-01. 9. Die erste Instanz des Zahlungsdienstes bestätigt der Warteschlange zahlungen die Erledigung. Danach löscht die Warteschlange den Auftrag.

Wann ist es sinnvoll und wann nicht?

Ein Point to Point Channel lohnt sich

Jeder Auftrag soll von nur einem Empfänger bearbeitet werden. Typische Fälle sind Zahlungen, Druckaufträge und das Versenden eines Briefes. Bekäme jede Instanz des Zahlungsdienstes eine eigene Ausfertigung desselben Auftrags, würde der Kunde 88123 die 1.200 Euro zweimal überwiesen bekommen. Mit einem Point to Point Channel erhält bei jedem Zustellversuch nur eine Instanz den Auftrag.
Mehrere gleichartige Empfänger sollen sich die Arbeit teilen. Die Versicherung betreibt mehrere Instanzen des Zahlungsdienstes, damit sich die Zahlungsaufträge auch dann nicht in der Warteschlange stauen, wenn viele Aufträge auf einmal kommen. Ohne Point to Point Channel müsste der Schadendienst selbst jeden Auftrag einer Instanz zuteilen und beim Ausfall einer Instanz eine andere wählen. Mit der Warteschlange holt sich jede Instanz den nächsten Auftrag selbst, und fällt eine Instanz aus, bearbeiten die übrigen Instanzen die Zahlungen weiter.
Kommen noch mehr Aufträge, lassen sich weitere Instanzen des Zahlungsdienstes starten. Die neuen Instanzen teilen sich die Aufträge der Warteschlange mit den vorhandenen, ohne dass der Schadendienst geändert wird.
Der Sender soll einen Auftrag abgeben können, ohne zu wissen, wie viele Instanzen des Empfängers gerade laufen und welche davon frei ist. Mit dem Point to Point Channel legt der Schadendienst den Auftrag nur in der Warteschlange zahlungen ab, und eine freie Instanz holt ihn dort ab.
Die Empfänger können jederzeit abstürzen oder neu gestartet werden. Ein Beispiel ist ein Update des Zahlungsdienstes. Ohne Warteschlange gingen Aufträge verloren, die der Schadendienst während des Updates an den Zahlungsdienst schickt. Die Warteschlange bewahrt die Aufträge auch dann auf, wenn alle Instanzen gleichzeitig ausgefallen sind.

Ein Point to Point Channel ist nicht das Richtige

Eine Nachricht interessiert mehrere verschiedene Programme. Die Nachricht „Schaden 4711 wurde bezahlt“ brauchen zum Beispiel Buchhaltung, Kundenportal und Statistik gleichermaßen. Eine Warteschlange gäbe die Nachricht aber nur einem dieser Programme. Stattdessen verschickt der Zahlungsdienst die Nachricht mit Publish Subscribe: Buchhaltung, Kundenportal und Statistik melden sich bei der Nachrichtenplattform an, und jedes dieser Programme bekommt eine eigene Ausfertigung jeder Nachricht. Der Zahlungsdienst schickt die Nachricht dafür nur einmal ab und muss sie nicht für jedes Programm in eine eigene Warteschlange legen.
Der Sender braucht sofort eine Antwort, bevor er weiterarbeiten kann. Ein Beispiel ist die Frage, ob eine Adresse gültig ist. Dann ruft der Sender den Empfänger direkt auf, etwa mit einem Remote Procedure Call, also einem Aufruf eines Programms auf einem anderen Rechner, und erhält die Antwort im selben Aufruf. Der Sender muss so nicht auf eine Antwort über eine zweite Warteschlange warten und sie seinem Auftrag zuordnen. Ist der Empfänger gerade ausgefallen, scheitert der Aufruf allerdings, und der Sender muss den Aufruf später selbst wiederholen, weil keine Warteschlange den Auftrag aufbewahrt.
Aufträge müssen strikt in der Reihenfolge ihres Eingangs erledigt werden, und trotzdem sollen mehrere Empfänger gleichzeitig arbeiten. Eine einfache Warteschlange kann die Stornierung zu Schaden 4711 an Kopie 1 geben, während Kopie 2 die Zahlung zu Schaden 4711 noch bearbeitet. Stattdessen stellt die Nachrichtenplattform alle Aufträge zum selben Schaden derselben Instanz zu, während die Instanzen verschiedene Schäden gleichzeitig bearbeiten. Die Reihenfolge gilt dann je Schaden, nicht über alle Aufträge. So kann eine Stornierung nicht vor der Zahlung zum selben Schaden erledigt werden. Wie das im Einzelnen geht, beschreibt Message Ordering.

Nachteile und typische Fehler

Mit einem Point to Point Channel muss jeder Empfänger doppelte Aufträge erkennen. Dafür braucht jeder Auftrag eine Kennung, und das Zahlungsregister muss die erledigten Zahlungen je Kennung zuverlässig speichern. Die Nachrichtenplattform ist ein zusätzliches Programm, das betrieben und überwacht werden muss. Mit der Wahl dieses Kanals ist außerdem festgelegt, dass nur eine Art von Empfänger zuständig ist. Soll später zum Beispiel auch die Buchhaltung jeden Zahlungsauftrag erhalten, muss das Team den Kanal umbauen, etwa auf Publish Subscribe.

Typische Fehler und woran man sie erkennt:

Doppelte Überweisung: Kopie 2 gibt die Überweisung an die Bank und wird neu gestartet, bevor sie der Warteschlange die Erledigung bestätigt. Nach Ablauf der Zustellfrist erhält Kopie 1 denselben Auftrag. Kopie 1 fragt das Zahlungsregister nicht und überweist die 1.200 Euro ein zweites Mal. Erkennbar ist das an zwei Überweisungen über 1.200 Euro an Kunde 88123 mit derselben Kennung.
Abgelaufene Zustellfrist: Die Zustellfrist beträgt zum Beispiel 30 Sekunden. Kopie 2 wartet 40 Sekunden auf die Bank und verlängert die Frist nicht. Nach 30 Sekunden gibt die Warteschlange den Auftrag frei und stellt ihn Kopie 1 zu, obwohl Kopie 2 noch daran arbeitet. Kopie 1 fragt das Zahlungsregister, und weil Kopie 2 die Zahlung noch nicht erfasst hat, antwortet das Zahlungsregister „nein“. Beide Instanzen überweisen dann die 1.200 Euro. Erkennbar ist das an erneuten Zustellungen, obwohl keine Instanz abgestürzt ist.
Bestätigung vor der Arbeit: Der Empfänger bestätigt den Auftrag gleich nach dem Abholen und überweist erst danach. Stürzt der Empfänger zwischen Bestätigung und Überweisung ab, hat die Warteschlange den Auftrag schon gelöscht, und die Zahlung fehlt. Erkennbar ist das an Zahlungsaufträgen im Schadendienst, zu denen es weder eine Überweisung noch einen Eintrag im Zahlungsregister gibt.
Vertauschte Reihenfolge: Der Schadendienst legt erst eine Zahlung zu Schaden 4711 und kurz danach ihre Stornierung in die Warteschlange. Kopie 2 erhält die Zahlung, Kopie 1 die Stornierung. Kopie 2 wartet noch auf die Bank, als Kopie 1 die Stornierung bearbeitet. Kopie 1 findet im Zahlungsregister keine Zahlung, die sie stornieren könnte, und die Stornierung läuft ins Leere. Danach gibt Kopie 2 die Überweisung an die Bank, obwohl die Zahlung storniert sein sollte. Erkennbar ist das an Stornierungen, zu denen zum Zeitpunkt ihrer Bearbeitung noch keine Zahlung erfasst war.

Weiterführend

Werkzeuge und Umsetzungen

RabbitMQ: Nachrichtenplattform, deren Warteschlangen eine Nachricht zunächst an einen Empfänger geben und sie erneut zustellen, wenn die Bestätigung ausbleibt.
Apache ActiveMQ Artemis: Nachrichtenplattform mit Warteschlangen nach dem Java Standard JMS, in dem dieser Kanal Queue heißt.
Apache Kafka: Nachrichtenplattform, die Nachrichten in Teilströmen speichert, den Partitionen. Innerhalb einer Gruppe von Empfängern liest jeweils nur ein Empfänger eine Partition. Für diese Gruppe wirkt das ähnlich wie eine Warteschlange, obwohl Kafka die Nachrichten nach dem Lesen nicht löscht.
NATS: Nachrichtenplattform, bei der sogenannte Queue Groups jede Nachricht an genau ein Mitglied der Gruppe verteilen.

Quellen

Bobby Woolf: Point-to-Point Channel: beschreibt das Muster aus dem Buch Enterprise Integration Patterns, nach dem nur ein Empfänger eine bestimmte Nachricht verarbeitet, auch wenn mehrere Empfänger am Kanal warten.
Microsoft: Service Bus queues, topics, and subscriptions: erläutert an einer Nachrichtenplattform das Sperren einer Nachricht für einen Empfänger, die erneute Zustellung nach Ablauf der Sperre oder einem Absturz und den Unterschied zwischen Warteschlangen und Publish Subscribe.