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.
Les applications stratégiques doivent fonctionner en permanence, même en cas de pannes non planifiées ou de sinistres. La résilience contre les pannes désastreuses des ressources de traitement des données constitue une exigence pour de nombreuses entreprises. Dans certains cas, elle est même requise par les réglementations du secteur.
Remarque
La récupération en cas de sinistre et la géoréplication de Service Bus vous aident à récupérer à partir de sinistres à grande échelle ou à laisser définitivement une région Azure défectueuse sans nécessiter de modifications à la configuration de votre application. Pour plus d’informations sur ces fonctionnalités et sur la façon d’activer la fiabilité et la résilience dans Azure Service Bus, consultez Fiabilité dans Azure Service Bus.
Si vous ne pouvez pas utiliser Geo-Disaster Recovery ou Geo-Replication pour répondre à vos besoins, vous pouvez déployer plusieurs espaces de noms Service Bus. Cet article décrit les techniques que vous pouvez utiliser pour protéger les applications contre une panne de service ou un sinistre potentiel à l’aide de plusieurs espaces de noms.
Types de réplication
Pour atteindre une résilience contre les sinistres avec le niveau Service Bus Standard, vous pouvez utiliser la réplication active ou passive. Si une file d’attente ou une rubrique doit rester disponible pendant une panne de centre de données, créez la même entité dans les deux espaces de noms. Les entités peuvent partager le même nom, car elles existent dans des espaces de noms distincts. Par exemple, vous pouvez atteindre une file d’attente principale sous contosoPrimary.servicebus.windows.net/myQueue, tandis que vous pouvez atteindre son équivalent secondaire sous contosoSecondary.servicebus.windows.net/myQueue.
Remarque
La réplication active et la configuration de la réplication passive sont des concepts à usage général et non des fonctionnalités spécifiques de Service Bus. La logique de réplication (c’est-à-dire l’envoi à 2 espaces de noms différents) se trouve dans les applications de l’expéditeur. Le destinataire doit avoir une logique personnalisée pour la détection des doublons.
Si l'application ne nécessite pas une communication permanente entre l'expéditeur et le destinataire, l'application peut implémenter une file d'attente côté client durable pour empêcher la perte de messages et protéger l'expéditeur contre toute erreur Service Bus temporaire.
Réplication active
La réplication active utilise des entités dans les deux espaces de noms pour chaque opération. Tout client qui envoie un message envoie deux copies du même message. La première copie est envoyée à l’entité principale (par exemple, contosoPrimary.servicebus.windows.net/sales) et la deuxième copie du message est envoyée à l’entité secondaire (par exemple, contosoSecondary.servicebus.windows.net/sales).
Un client reçoit des messages des deux files d'attente. Le destinataire traite la première copie d'un message et la deuxième copie est supprimée. Pour supprimer les messages en double, l'expéditeur doit attribuer un identificateur unique à chaque message. Les deux copies du message doivent avoir le même identificateur. Vous pouvez utiliser les propriétés ServiceBusMessage.MessageId ou ServiceBusMessage.Subject, ou une propriété personnalisée pour marquer le message. Le destinataire doit conserver une liste de messages qu’il a déjà reçus.
Remarque
L'approche de réplication active double le nombre d'opérations ; par conséquent, cette approche peut mener à un coût plus élevé.
Réplication passive
En cas d'absence de panne, la réplication passive n'utilise qu'une seule des deux entités de messagerie. Un client envoie le message à l'entité active. Si l'opération sur l'entité active échoue avec un code d'erreur qui indique que le centre de données qui héberge l'entité active n'est pas disponible, le client envoie une copie du message à l'entité de sauvegarde. À ce stade, les entités active et de sauvegarde permutent leurs rôles. Le client à l'origine de l'envoi considère que l'ancienne entité active est la nouvelle entité de sauvegarde, et que l'ancienne entité de sauvegarde est la nouvelle entité active. Si les deux opérations d'envoi échouent, les rôles des deux entités restent inchangés et une erreur est renvoyée.
Un client reçoit des messages des deux files d'attente. Étant donné qu'il est possible que le destinataire reçoive deux copies du même message, le destinataire doit supprimer les messages en double. Vous pouvez supprimer les doublons de la même façon que celle décrite pour la réplication active.
En général, la réplication passive est moins onéreuse que la réplication active, car dans la plupart des cas, une seule opération est effectuée. La latence, le débit et le coût monétaire sont identiques au scénario de la non réplication.
Lorsque vous utilisez la réplication passive, dans les scénarios suivants, les messages peuvent être perdus ou reçus deux fois :
- Retard ou perte de message : Supposons que l’expéditeur a envoyé avec succès un message m1 à la file d’attente principale, et qu’ensuite la file d'attente devient indisponible avant que le destinataire ne reçoive m1. L'expéditeur envoie un message ultérieur m2 à la file d'attente secondaire. Si la file d'attente principale est temporairement indisponible, le destinataire reçoit m1 lorsque la file d'attente est à nouveau disponible. Délai ou perte de message : supposons que l'expéditeur ait envoyé avec succès un message m1 à la file d'attente primaire, puis que la file d'attente devienne indisponible avant que le destinataire ne reçoive m1.
- Réception de doublons : Supposons que l'expéditeur envoie un message m à la file d'attente principale. Service Bus traite m avec succès mais ne parvient pas à envoyer une réponse. Après expiration de l'opération d'envoi, l'expéditeur envoie une copie identique de m à la file d'attente secondaire. Si le destinataire peut recevoir la première copie de m avant que la file d'attente principale ne devienne indisponible, le destinataire reçoit les deux copies de m approximativement au même moment. Si le destinataire ne peut pas recevoir la première copie de m avant que la file d'attente principale ne devienne indisponible, le destinataire ne reçoit initialement que la deuxième copie de m, mais reçoit ensuite une deuxième copie de m lorsque la file d'attente principale devient disponible.
L'exemple Tâches de réplication Azure Messaging avec .NET Core illustre la réplication de messages entre des espaces de noms.
Étapes suivantes
Pour plus d'informations sur la récupération d'urgence, consultez les articles suivants :