Clusterthemen
Themen lassen sich auf ähnliche Weise wie Clusterwarteschlangen in Gruppen zusammenfassen, wobei ein Themenobjekt jedoch jeweils nur Mitglied eines einzigen Clusters sein kann. Ein Thema (Topic) wird zu einem Cluster-Topic, indem im Themenobjekt der Name des Clusters, der das Thema enthalten soll, und der Mechanismus zur Clusterweiterleitung, der für Publikationen in diesem Thema verwendet werden soll, festgelegt werden.
- DIRECT
- TOPICHOST
Standardmäßig hat das Topic-Routing den Wert DIRECT. Dies war die einzige Option vor IBM® MQ 8.0. Wenn Sie ein direkt geroutetes Cluster-Topic in einem Warteschlangenmanager konfigurieren, werden sämtliche Warteschlangenmanager im Cluster aller anderen Warteschlangenmanager im Cluster gewahr. Bei Publish/Subscribe-Vorgängen stellt jeder Warteschlangenmanager dann eine direkte Verbindung zu allen anderen Warteschlangenmanagern her.
Ab IBM MQ 8.0 können Sie die themenbasierte Weiterleitung (Topic-Routing) stattdessen mit dem Wert TOPICHOST konfigurieren. Bei Verwendung der Routing-Option "TOPICHOST" werden sich alle Warteschlangenmanager des Clusters über diejenigen Clusterwarteschlangenmanager bewusst, auf denen die weitergeleiteten Themendefinitionen bereitgestellt werden. Bei der Durchführung von Veröffentlichungs- und Subskriptionsoperationen stellen Warteschlangenmanager im Cluster nur mit den TOPICHOST-Warteschlangenmanagern eine Verbindung her, nicht direkt miteinander. Die Topic-Host-Warteschlangenmanager sind für das Routing von Publikationen aus Warteschlangenmanagern verantwortlich, in denen Publikationen für Warteschlangenmanager mit übereinstimmenden Subskriptionen veröffentlicht werden.
- Verbesserte Skalierbarkeit größerer Cluster. Nur die TOPICHOST-Warteschlangenmanager müssen mit allen anderen Warteschlangenmanagern im Cluster eine Verbindung herstellen können. Deshalb gibt es weniger Kanäle zwischen den Warteschlangenmanagern und zwischen den Warteschlangenmanagern weniger Datenverkehr in Verbindung mit der Publish/Subscribe-Verwaltung, als dies beim direkten Routing der Fall ist. Wenn sich die Subskriptionen auf einem Warteschlangenmanger ändern, müssen nur die Topic-Host-Warteschlangenmanager informiert werden.
- Größere Kontrollmöglichkeiten bei der physischen Konfiguration. Beim direkten Routing setzen alle Warteschlangenmanager sämtliche Rollen voraus und müssen daher gleichermaßen befähigt sein. Beim Topic-Host-Routing wählen Sie die Warteschlangenmanager, die als Topic-Host fungieren, explizit aus. Sie können für diese Warteschlangenmanager also gezielt leistungsstärkere Computer auswählen und für die anderen Warteschlangenmanager weniger leistungsstarke Systeme verwenden.
Auswirkung des Definierens eines lokalen Themas sowie eines Cluster-Topics
Sie definieren ein lokales Topic-Objekt, wenn Publisher-Anwendungen, die mit einem Warteschlangenmanager verbunden sind, nur für lokal verbundene Subskribenten veröffentlichen sollen. Die lokale Definition eines Topics überschreibt stets alle Cluster-Topic-Definitionen in fernen Warteschlangenmanagern.
Mehrere Cluster-Topic-Definitionen in einem Cluster mit direktem Routing
In einem Cluster mit direktem Routing definieren Sie ein Cluster-Topic für gewöhnlich nicht in mehreren Clusterwarteschlangenmanagern, da das Topic über das direkte Routing allen Warteschlangenmanagern im Cluster zur Verfügung steht.
Zudem ist es nicht erforderlich, dass der einzige Host-Warteschlangenmanager ununterbrochen zur Verfügung steht, da die Definition des Cluster-Topics vom vollständigen Warteschlangenmanager-Repository und von allen anderen Warteschlangenmanagern in ihren partiellen Clusterrepositorys zwischengespeichert wird. Dadurch ist eine Verfügbarkeit von mindestens 60 Tagen sichergestellt, wenn der Host-Warteschlangenmanager nicht verfügbar ist.
Wenn Sie die Definition eines Cluster-Topics ändern müssen, achten Sie darauf, sie in dem Warteschlangenmanager zu ändern, in dem sie auch definiert wurde.
Mehrere Cluster-Topic-Definitionen in einem Cluster mit Topic-Host-Routing
In einem Cluster mit Topic-Host-Routing wird das gesamte Publish/Subscribe-Messaging über die Topic-Hosts geroutet. Um die Skalierbarkeit und Verfügbarkeit sicherzustellen, wird daher für gewöhnlich ein Cluster-Topic in mehreren Warteschlangenmanagern definiert und die mehrfachen Cluster-Topic-Definitionen sind in der Regel identisch.