Service Broker

  • Article

S’applique à :SQL ServerAzure SQL Managed Instance

SQL Server Service Broker fournit une prise en charge native de la messagerie et de la mise en file d’attente dans le Moteur de base de données SQL Server et Azure SQL Managed Instance. Les développeurs peuvent créer plus facilement des applications perfectionnées qui utilisent les composants de Moteur de base de données pour la communication entre des bases de données disparates, et créer des applications fiables et distribuées.

Quand utiliser Service Broker ?

Utilisez les composants de Service Broker pour implémenter des fonctionnalités natives de traitement des messages asynchrones dans la base de données. Les développeurs d'applications qui utilisent Service Broker peuvent distribuer les charges de données sur plusieurs bases de données sans développer des mécanismes de messagerie et de communication complexes. Service Broker réduit le travail de développement et de test car Service Broker gère les chemins de communication dans le contexte d’une conversation. Les performances sont aussi meilleures. Par exemple, les bases de données frontales prenant en charge les sites Web peuvent enregistrer des informations et mettre des tâches intensives en file d'attente dans des bases de données principales. Service Broker garantit que toutes les tâches sont gérées dans le contexte des transactions afin d’assurer une fiabilité et une cohérence techniques.

Vue d’ensemble

Service Broker est un framework de remise de message qui vous permet de créer des applications natives orientées service dans la base de données. Contrairement aux fonctionnalités de traitement des requêtes classiques qui lisent constamment les données à partir des tables et les traitent au cours du cycle de vie de requête, dans une application orientée service vous avez des services de base de données qui échangent des messages. Chaque service dispose d’une file d’attente où les messages sont placés jusqu’à ce qu’ils soient traités.

Service broker

Les messages dans les files d’attente peuvent être extraits à l’aide de la commande Transact-SQL RECEIVE ou par la procédure d’activation qui est appelée chaque fois que le message arrive dans la file d’attente.

Création de services

La création des services de base de données s’effectue à l’aide de l’instruction Transact-SQL CREATE SERVICE. Le service peut être associée à la file d’attente de message créée à l’aide de l’instruction CREATE QUEUE :

CREATE QUEUE dbo.ExpenseQueue;
GO
CREATE SERVICE ExpensesService
    ON QUEUE dbo.ExpenseQueue;

Envoi de messages

Les messages sont envoyés sur la conversation entre les services à l’aide de l’instruction Transact-SQL SEND. Une conversation est un canal de communication établi entre les services à l’aide de l’instruction Transact-SQL BEGIN DIALOG.

DECLARE @dialog_handle UNIQUEIDENTIFIER;

BEGIN DIALOG @dialog_handle  
FROM SERVICE ExpensesClient  
TO SERVICE 'ExpensesService';  
  
SEND ON CONVERSATION @dialog_handle (@Message) ;

Le message est envoyé vers ExpenssesService et placé dans dbo.ExpenseQueue. Comme aucune procédure d’activation n’est associée à cette file d’attente, le message reste dans la file d’attente jusqu’à ce qu’un utilisateur le lise.

Traitement des messages

Les messages placés dans la file d’attente peuvent être sélectionnés à l’aide d’une requête SELECT standard. L’instruction SELECT ne modifie pas la file d’attente et ne supprime pas les messages. Pour lire et extraire les messages de la file d’attente, vous pouvez utiliser l’instruction Transact-SQL RECEIVE.

RECEIVE conversation_handle, message_type_name, message_body  
FROM ExpenseQueue;

Une fois que vous avez traité tous les messages de la file d’attente, vous devez fermer la conversation à l’aide de l’instruction Transact-SQL END CONVERSATION.

Emplacement de la documentation de Service Broker

La documentation de référence pour Service Broker est incluse dans la documentation de SQL Server . Cette documentation de référence comprend les sections suivantes :

Consultez la documentation précédemment publiée pour les concepts Service Broker et pour les tâches de gestion et de développement. Cette documentation n'est pas reproduite dans la documentation de SQL Server en raison du petit nombre de changements apportés à Service Broker dans les versions récentes de SQL Server.

Nouveautés dans Service Broker

Service Broker et Azure SQL Managed Instance

L’échange de messages inter-instances de Service Broker entre les instances d’Azure SQL Managed Instance et l’échange de messages entre SQL Server et Azure SQL Manage Instance est actuellement en phase de prévision publique :

  • CREATE ROUTE :le port spécifié doit être 4022. Voir CREATE ROUTE.
  • ALTER ROUTE :le port spécifié doit être 4022. Voir ALTER ROUTE.

La sécurité du transport est prise en charge, pas la sécurité du dialogue :

  • CREATE REMOTE SERVICE BINDING n’est pas pris en charge.

Service Broker est activé par défaut et ne peut pas être désactivé. Les options ALTER DATABASE suivantes ne sont pas prises en charge :

  • ENABLE_BROKER
  • DISABLE_BROKER

Aucune modification importante n’a été introduite dans SQL Server 2019 (15.x). Les modifications suivantes ont été introduites dans SQL Server 2012 (11.x).

Les messages peuvent être envoyés à des services cibles (multidiffusion).

La syntaxe de l’instruction SEND (Transact-SQL) a été étendue pour permettre la multidiffusion au moyen de la prise en charge de plusieurs descripteurs de conversation.

Les files d'attente exposent le temps d'empilement des messages.

Les files d’attente ont une nouvelle colonne, message_enqueue_time, qui indique depuis combien de temps un message est dans la file d’attente.

La gestion des messages incohérents peut être désactivée

Les instructions CREATE QUEUE (Transact-SQL) et ALTER QUEUE (Transact-SQL) ont désormais la possibilité d’activer ou désactiver la gestion des messages incohérents en ajoutant la clause POISON_MESSAGE_HANDLING (STATUS = ON | OFF). L’affichage catalogue sys.service_queues comprend maintenant la colonne is_poison_message_handling_enabled pour indiquer si le message incohérent est activé ou désactivé.

Prise en charge d’Always On dans Service Broker

Pour plus d’informations, consultez Service Broker avec les groupes de disponibilité Always On (SQL Server).

Étapes suivantes

L’utilisation la plus courante de Service Broker concerne les notifications d’événements. Découvrez comment Implémenter des notifications d'événements, Configurer la sécurité du dialogue ou Obtenir plus d’informations.