Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :
SQL ServerAzure SQL Managed Instance
Cet article décrit les détails de la façon dont Service Broker achemine les messages. Pour obtenir une vue d’ensemble, consultez Routes.
Pour la plupart des applications, une simple approche du routage Service Broker fonctionne bien. Il suffit d'indiquer, dans chaque base de données contenant un service, un itinéraire pour les services externes avec lesquels le service communique. Toutefois, Service Broker fournit également un système de routage perfectionné pour traiter les cas où une application nécessite un comportement plus complexe. Pour obtenir des exemples illustrant le processus de routage, consultez les exemples de routage Service Broker.
Description du processus de routage
SQL Server gère deux niveaux distincts d’informations de routage. Chaque base de données contient une table de routage locale, sys.routespour les conversations commencées dans cette base de données. Pour les conversations lancées à partir de l’instance de SQL Server, SQL Server effectue la recherche dans la table de routage de la base de données qui a créé la conversation. Pour les conversations provenant de l’extérieur de l’instance, SQL Server recherche msdb.sys.routes.
Le processus de concordance est le même à la base, que la conversation démarre à l'intérieur ou à l'extérieur de l'instance. Il ignore les itinéraires qui ont expiré. Le processus de routage est composé de trois étapes distinctes :
Rechercher des itinéraires correspondants : Service Broker recherche un ensemble d’itinéraires possibles en correspondant au nom du service et à l’identificateur Service Broker.
Choisissez un itinéraire : Service Broker choisit un itinéraire parmi l’ensemble des itinéraires possibles.
Localisez le service de destination : lorsque l’itinéraire choisi spécifie
'LOCAL'comme adresse réseau, Service Broker localise le service dans l’instance. Si le service n’existe pas dans l’instance, Service Broker peut revenir à l’étape 2 et choisir un autre itinéraire.
Quand un message est envoyé par l’initiateur à la cible et qu’il reçoit un message d’accusé de réception de la cible, l’initiateur utilise l’identificateur Service Broker du message d’accusé de réception pour router les messages suivants vers la même cible. Service Broker traite les messages d’accusé de réception, ce processus est transparent pour une application qui utilise Service Broker. Pour plus d’informations sur les messages d’accusé de réception, consultez les protocoles de communication de Service Broker.
Répondre aux messages d’un service cible
Quand un message d’un service cible arrive dans l’instance, SQL Server vérifie si l’instance actuelle contient l’identificateur Service Broker dans le message. Si c’est le cas, le message est remis dans l’instance actuelle, comme décrit dans Localiser le service de destination plus loin dans cet article. Sinon, SQL Server suit le processus de correspondance standard.
Rechercher des itinéraires correspondants
La procédure suivante décrit comment SQL Server fait correspondre les routes. À chaque étape, si une ou plusieurs routes correspondent, le processus de mise en correspondance se termine et Service Broker choisit une des routes correspondantes de la façon suivante :
Si la conversation spécifie un identificateur Service Broker, recherche une route qui a une correspondance exacte pour le nom du service et l’identificateur Service Broker.
Recherchez une correspondance exacte pour le nom du service entre les itinéraires qui ne spécifient pas d’identificateur Service Broker.
Si la conversation ne spécifie pas d’identificateur Service Broker, recherchez une correspondance exacte pour le nom du service parmi les itinéraires qui spécifient un identificateur Service Broker. Si la table de routage contient des routes qui correspondent au nom du service et qui ont des identificateurs Service Broker différents, choisit arbitrairement un identificateur Service Broker. Ensuite, fait correspondre uniquement les routes qui utilisent cet identificateur Service Broker.
Si un itinéraire menant à un service de routage dynamique est présent et qu'aucune demande d'itinéraire vers ce service n'est en attente, marquez la conversation comme étant retardée et demandez des informations sur le routage auprès de ce service.
Recherche une route qui spécifie ni le nom du service ni l’identificateur Service Broker.
Si la conversation spécifie un identificateur Service Broker et si l’instance contient une ou plusieurs bases de données contenant des services avec des noms correspondant au nom spécifié dans la conversation, routez la conversation comme si la table de routage contenait un itinéraire avec le nom du service et l’adresse
'LOCAL'réseau.Marquez la conversation comme étant retardée.
Lorsqu’une conversation est marquée comme retardée, Service Broker effectue à nouveau le processus de correspondance après une période d’expiration. L’échec de la recherche d’un itinéraire correspondant n’est pas considéré comme une erreur.
Choisir un itinéraire
Si le processus de mise en correspondance trouve plusieurs routes correspondantes, Service Broker en choisit une parmi elles. À cet effet, les routes qui ont le même identificateur Service Broker, le même nom de service et la même adresse réseau sont considérées comme étant identiques. Service Broker utilise la procédure suivante pour choisir la route exacte. À la fin de chaque étape, le processus se poursuit à l'étape suivante si aucun itinéraire correspondant aux caractéristiques de l'adresse n'est trouvé.
Choisissez un itinéraire parmi ceux qui spécifient une adresse miroir.
Choisissez un itinéraire parmi les itinéraires qui spécifient
'LOCAL'comme adresse réseau. Si cette instance de SQL Server ne contient pas de service qui correspond au nom spécifié dans la conversation, poursuivez à l’étape 3.Choisissez un itinéraire parmi ceux qui spécifient une adresse réseau.
Choisissez un itinéraire parmi les itinéraires qui spécifient
'TRANSPORT'comme adresse réseau.
Si le transfert de messages par le broker n’est pas actif, Service Broker abandonne le message si la conversation ne prend pas son origine dans l’instance actuelle et que l’adresse de l’itinéraire choisi n’est pas 'LOCAL'.
Localiser le service de destination
Comme décrit précédemment, Service Broker remet des messages à un service dans l’instance actuelle lorsque l’itinéraire correspondant spécifie 'LOCAL' comme adresse réseau. Pour les messages qui proviennent de l’extérieur de l’instance, l’itinéraire doit se trouver dans msdb.sys.routes. Pour les messages qui proviennent de l’instance, l’itinéraire correspondant doit se trouver dans la sys.routes table de la base de données qui lance la conversation.
Quand Service Broker détermine que le service du message se trouve dans l’instance actuelle, il cherche à localiser ce service dans l’instance. Quand un identificateur Service Broker pour la conversation existe dans la conversation ou dans la route, Service Broker remet les messages à la base de données identifiée par l’identificateur Service Broker.
Sinon, Service Broker localise le service en commençant par rechercher le nom du service dans la base de données qui contient la conversation. Ensuite, il recherche le nom du service dans les autres bases de données de l’instance. Service Broker remet le message au premier service localisé. Toutefois, l’ordre dans lequel Service Broker recherche les autres bases de données d’une instance n’est pas spécifié et n’est pas garanti pour être cohérent de la conversation à la conversation. Autrement dit, s’il existe plusieurs exemplaires du service cible dans l’instance, Service Broker choisit de façon aléatoire le service à cibler.
Autres considérations
Pour améliorer la fiabilité, le routage Service Broker contient des protections contre les boucles de routage. Le routage Service Broker prend en charge la mise en miroir des bases de données et peut rediriger les conversations de manière transparente vers le partenaire actif d’une base de données en miroir.
Boucles de routage
Le transfert de messages Service Broker surveille le nombre de fois qu’un message est transféré afin d’éviter les boucles de routage sans fin. Pour plus d’informations, consultez transfert de messages Service Broker.
Si la route correspondante contient une adresse réseau qui se résout sur l’instance actuelle, SQL Server traite la conversation comme si elle était lancée en dehors de l’instance. Service Broker achemine les messages de la conversation à l’aide des itinéraires dans msdb.sys.routes. Le routage de ces messages est identique au routage des messages qui proviennent de l'extérieur de l'instance. En particulier, le transfert de messages doit être actif pour que Service Broker transfère le message à une adresse réseau autre que 'LOCAL'.
Adresses miroir
Les itinéraires indiquant des adresses miroir jouissent de la plus haute priorité au moment où un itinéraire est choisi dans l'ensemble des itinéraires répertoriés au départ. Toutefois, Service Broker ne prend pas en compte les adresses miroir lors de la recherche d’itinéraires correspondants pour une conversation.
Lorsque Service Broker choisit un itinéraire qui spécifie une adresse miroir et que Service Broker n’a pas précédemment remis un message à l’aide de l’itinéraire, Service Broker envoie une demande aux deux adresses pour déterminer quelle instance est actuellement le principal. Une fois l’instance identifiée, Service Broker envoie tous les messages qui utilisent la route à l’instance principale sans contacter l’instance miroir. Si le principal est inaccessible ou que cette instance indique qu’elle n’est plus le principal, Service Broker envoie des messages à l’autre adresse de la paire si l’instance de SQL Server à l’autre adresse indique qu’il s’agit du nouveau principal.
Dans les cas où Service Broker ne peut pas atteindre le principal, mais que le partenaire ne prétend pas être nouveau principal, Service Broker n’envoie pas de messages au partenaire. Service Broker va essayer à nouveau l'adresse du principal puis celle du partenaire jusqu'à ce que le principal soit accessible ou que le partenaire devienne le principal. En adoptant cette approche, Service Broker remet de manière fiable les messages lorsque le principal et le partenaire peuvent communiquer, mais que l’instance envoyant le message ne peut pas atteindre le principal.