Les clusters de messagerie ${build.shortName} permettent de regrouper des groupes de serveurs de messagerie ${build.shortName} afin de partager la charge de traitement des messages. Chaque nœud actif du cluster est un serveur de messagerie ${build.shortName} actif qui gère ses propres messages et ses propres connexions.
Le cluster est formé par chaque nœud déclarant des connexions de cluster à d'autres nœuds dans le fichier de configuration ${build.shortName}. Lorsqu'un nœud forme une connexion de cluster avec un autre nœud, il crée, en interne, une connexion core api entre lui-même et l'autre nœud. Cela se fait de manière transparente dans les coulisses ; vous n'avez pas besoin de déclarer un api explicite pour chaque nœud. Ces connexions cluster permettent aux messages de circuler entre les nœuds du cluster pour équilibrer la charge.
Pour une documentation complète sur le clustering, voir Aperçu sur les clusters.
Cette section contient la configuration pour les sujets suivants :
Un groupe de diffusion est le moyen par lequel un serveur diffuse des connecteurs sur le réseau. Un connecteur définit la manière dont un client, ou un autre serveur, peut établir des connexions au serveur.
Le groupe de diffusion prend un ensemble de connecteurs et les diffuse sur le réseau. Selon la technique de diffusion que vous configurez le cluster, il utilise UDP ou JGroups pour diffuser des informations sur les paires de connecteurs.
Les groupes de diffusion sont définis dans le sous-système messaging-activemq de la configuration de serveur. Il peut y avoir plusieurs groupes de diffusion par serveur de messagerie ${build.shortName}.
Alors que le groupe de diffusion définit comment l'information sur les connecteurs est diffusée à partir d'un serveur, un groupe discovery définit comment l'information sur les connecteurs est reçue à partir d'un point d'extrémité de diffusion, par exemple, une adresse multicast UDP ou un canal JGroup.
Un groupe discovery maintient une liste de connecteurs, un pour chaque diffusion par un serveur différent. Lorsqu'il reçoit des émissions sur le point final de diffusion à partir d'un serveur particulier, il met son entrée à jour dans la liste dédiée à ce serveur. S'il n'a pas reçu de diffusion d'un serveur particulier pendant un certain temps, il supprimera l'entrée de dédiée à ce serveur dans sa liste.
Regrouper les connexions de serveurs de groupe en clusters afin que les messages puissent être chargés de manière équilibrée entre les nœuds du cluster. Les connexions de cluster sont définies dans la configuration de serveur ${build.shortName} en utilisant l'élément de connexion cluster. Il peut y avoir zéro ou plusieurs connexions de cluster définies par serveur de messagerie ${build.shortName}.
Dans un cluster, les groupes de messages avec des ID de groupe spécifiques peuvent arriver sur n'importe lequel des nœuds. Il est important pour un nœud de déterminer quels identificateurs de groupe sont liés à quel consommateur et sur quel nœud. Chaque nœud est responsable de l'acheminement correct des groupes de messages vers le nœud qui a le consommateur traitant ces identifiants de groupe, indépendamment de l'endroit où les groupes de messages arrivent par défaut. Une fois que des messages ayant un identifiant de groupe donné sont envoyés à un consommateur spécifique connecté au nœud donné dans le cluster, ces messages ne sont jamais envoyés à un autre nœud même si le consommateur est déconnecté.
Cette situation est traitée par un gestionnaire (ou handler) de regroupement. Chaque nœud dispose d'un gestionnaire de regroupement et ce gestionnaire de regroupement (avec d'autres gestionnaires) est responsable de l'acheminement des groupes de messages vers le nœud qui convient.
La fonction d'une api est de consommer les messages d'une destination et de les transférer à une autre, typiquement sur un serveur de messagerie ${build.shortName} différent.
Les serveurs source et cible n'ont pas besoin d'être dans le même cluster, ce qui permet d'envoyer de manière fiable des messages d'un cluster à l'autre, par exemple, à travers un WAN ou Internet et quand la connexion peut ne pas être fiable.
L'api a une résilience intégrée à la défaillance, de sorte que si la connexion du serveur cible est perdue, par exemple, en raison d'une défaillance du réseau, l'api essayera à nouveau de se connecter à la cible jusqu'à ce qu'elle revienne en ligne. Lorsqu'il sera de nouveau en ligne, il reprendra son fonctionnement normal.
Les ponts sont un moyen fiable de connecter deux serveurs de messagerie ${build.shortName} séparés ensemble. Avec un core api, les serveurs source et cible doivent être des serveurs de messagerie ${build.shortName}.