ApsaraMQ for RabbitMQ fournit un service de messagerie hautement disponible, compatible avec RabbitMQ, qui prend en charge le protocole AMQP 0-9-1. Le contrat de niveau de service (SLA) du produit garantit la disponibilité du service côté plateforme, ce qui n'équivaut pas à une disponibilité de bout en bout à 100 % pour votre activité.
SLA du produit et disponibilité métier
Conformément au Contrat de niveau de service officiel ApsaraMQ for RabbitMQ, la disponibilité du service est mesurée par instance sur une base mensuelle calendaire. L'engagement de base stipulé dans le contrat actuel est d'au moins 99,95 %. Sur la base d'un mois calendaire de 30 jours, 99,95 % correspondent à environ 21,6 minutes d'indisponibilité telles que définies par le contrat. Cette valeur illustre uniquement la métrique du SLA et ne définit pas la fenêtre d'erreur acceptable pour votre activité. Les calculs réels sont soumis aux définitions de l'indisponibilité du service, aux exclusions et au contrat en vigueur au moment de l'achat.
La disponibilité métier est également influencée par la reconnexion du client, les conditions réseau et DNS, le déploiement des applications, la capacité de traitement de la consommation, les capacités de traitement idempotent, les sinistres interrégionaux, le cycle de vie des versions et les configurations spécifiques au client. Si votre objectif de continuité d'activité dépasse le SLA d'une seule instance, vous devez mettre en place des capacités de basculement, d'idempotence des messages et d'architecture multi-instances et multirégion, tant au niveau de l'application qu'au niveau de l'architecture des ressources.
Les métriques du SLA peuvent varier selon le type d'instance ou la spécification. Les droits spécifiques dépendent de la page d'achat, du site Web officiel d'Alibaba Cloud et du contrat en vigueur au moment de l'achat. Une solution multi-instances ne crée pas un nouveau SLA de produit, et vous ne pouvez pas multiplier les SLA de deux instances. La disponibilité métier dépend de l'isolation des pannes, de la synchronisation des messages, du basculement du client et de l'efficacité des tests de simulation.
Limites architecturales
ApsaraMQ for RabbitMQ est compatible avec le protocole AMQP 0-9-1 et utilise une architecture gérée multi-nœuds côté serveur. Les méthodes d'accès telles que le point de terminaison public, le VPC et le point d'accès via connexion au réseau privé PrivateLink sont soumises à la console et à la documentation officielle.
ApsaraMQ for RabbitMQ améliore la disponibilité des instances grâce aux capacités multi-nœuds et multi-zones. Le côté serveur utilise plusieurs nœuds pour gérer les connexions et les requêtes. Lorsqu'un seul nœud ou une seule zone côté serveur rencontre une anomalie, les capacités multi-nœuds aident à réduire l'impact sur la disponibilité de l'instance. Les capacités spécifiques dépendent du type d'instance, de la région et de la page d'achat.
Les connexions clientes sont gérées au niveau de la Connection. L'établissement de plusieurs Connections persistantes permet de répartir le trafic plus uniformément sur plusieurs nœuds, mais ne garantit pas que chaque Connection atterrit sur un nœud différent. La création de plusieurs Channels sur une seule AMQP Connection améliore le multiplexage concurrent au sein de cette Connection, mais ne peut pas remplacer la distribution des nœuds côté serveur au niveau de la Connection. Pour les charges de travail à haute concurrence ou critiques, établissez plusieurs Connections persistantes et répartissez les producteurs et les consommateurs sur le pool de connexions afin d'éviter de concentrer tout le trafic sur une ou quelques Connections.
Les scénarios suivants ne sont pas pris en charge par une architecture à instance unique :
Pannes au niveau de la région, pannes réseau interrégionales ou anomalies du VPC, du DNS ou du groupe de sécurité côté client
Clients n'ayant pas configuré la reconnexion automatique, la reconstruction de Channel ou la réabonnement des consommateurs
Clients utilisant uniquement quelques Connections persistantes, ce qui entraîne une distribution insuffisante du trafic sur les nœuds côté serveur
Traitement lent des consommateurs, échecs de traitement métier, accumulation de messages ou limitation due au dépassement des quotas
Absence de traitement idempotent, entraînant une consommation en double, une livraison hors ordre ou des effets secondaires métier lors du basculement ou de la relecture
Améliorations côté client
Quelle que soit la solution de déploiement que vous sélectionnez, vérifiez que votre implémentation cliente répond aux exigences suivantes. Pour obtenir des conseils complets, consultez les Notes d'utilisation du SDK et les bonnes pratiques pour l'utilisation d'un client Spring Boot.
Reconnexion automatique — Reconstruisez automatiquement la Connection après une déconnexion. Selon le SDK que vous utilisez, vérifiez les capacités de récupération de la topologie et des consommateurs. Pour plus d'informations, consultez la rubrique Configurer la reconnexion automatique pour un client.
Multiples Connections pour la répartition du trafic — Configurez plusieurs Connections persistantes en fonction de votre concurrence de production et de consommation et du quota de Connection de l'instance. Utilisez des Connections distinctes pour la production et la consommation. Ne concentrez pas toute la production et la consommation sur une seule Connection et évitez de créer et de fermer fréquemment des Connections. Pour les recommandations générales, consultez la rubrique Connections et channels. Pour les clients Spring, consultez les bonnes pratiques pour l'utilisation d'un client Spring Boot.
Reconstruction de Channel — Les Channels RabbitMQ ne sont pas des ressources permanentes. En cas d'exceptions de protocole, de conflits de déclaration de ressources ou de limitation, reconstruisez le Channel. Pour les conflits de déclaration de ressources, corrigez d'abord les paramètres de déclaration. Dans les scénarios de limitation, appliquez un backoff et un délestage avant la reconstruction pour éviter de créer des boucles de reconstruction. Les Channels peuvent réutiliser les Connections, mais ne peuvent pas remplacer la distribution des nœuds côté serveur au niveau de la Connection. Pour plus d'informations, consultez les bonnes pratiques relatives à la limitation des instances.
Récupération des consommateurs — Après la reconnexion, rétablissez les abonnements des consommateurs en restaurant
basic.consumeet les rappels des consommateurs. Vérifiez que le comportement de récupération des Queues exclusives, des Consumer Tags et d'autres ressources après la reconnexion répond à vos attentes.Publisher Confirm — Utilisez Publisher Confirm côté production pour déterminer si le serveur a reçu et pris en charge le message. Publisher Confirm ne signifie pas que le consommateur a traité le message. En cas d'expiration du délai de confirmation ou d'absence d'accusé de réception, effectuez une nouvelle tentative avec le même ID de message métier en suivant les règles d'idempotence.
ACK et retry des consommateurs — Effectuez un ACK uniquement après un traitement métier réussi. En cas d'échec, exécutez reject, nack, une retry avec un nombre limité ou routez vers une dead letter queue en fonction de votre stratégie métier. Évitez les requeue infinies qui créent des boucles de retry.
Traitement idempotent — La production, le routage, le basculement et la relecture peuvent tous générer des messages en double. Le producteur doit maintenir un ID de message métier stable pour le même message métier, et le consommateur doit effectuer une déduplication par ID métier. Pour plus d'informations, consultez la rubrique Idempotence des messages.
Limitation et disjoncteur — Lorsque l'instance est anormale ou que le système en aval n'est pas sain, le producteur doit appliquer une limitation et un backoff avec des limites supérieures sur les retries pour éviter l'amplification des retries, l'accumulation et les pannes en cascade. Pour plus d'informations, consultez les bonnes pratiques relatives à la limitation des instances.
Actualisation de l'adresse d'accès — Si vous changez d'instances via un centre de configuration ou des noms de domaine gérés par le client, le client doit prendre en charge l'actualisation de l'adresse d'accès pour éviter de conserver indéfiniment des adresses obsolètes. Lors de l'utilisation de noms de domaine gérés par le client, vérifiez le TTL DNS, la mise en cache DNS du client ou de la JVM et le comportement de vérification du nom d'hôte TLS.
Solutions recommandées
Les sections suivantes décrivent quatre solutions de déploiement avec des niveaux de disponibilité croissants. Le tableau suivant résume chaque solution pour vous aider à identifier celle qui convient le mieux à votre charge de travail. Outre les considérations spécifiques à chaque solution, vérifiez que votre client répond aux exigences décrites dans la section Améliorations côté client.
Pour les charges de travail nécessitant une stabilité supérieure, une isolation des ressources ou une prévisibilité de la capacité, sélectionnez l'édition Platinum ou l'édition Serverless Exclusive. Les capacités spécifiques et les termes du SLA dépendent de la description du type d'instance et de la page d'achat.
|**Solution**
|
**Champ d'application**
|
**Prérequis clés**
|
**Limitation clé**
| | --- | --- | --- | --- | |
Ligne de base à instance unique
|
Chemins non critiques avec des exigences RTO/RPO souples
|
Reconnexion du client, surveillance et alertes
|
SLA de la plateforme du type d'instance uniquement
| |
Standby double instance dans la même région
|
Charges de travail principales nécessitant une récupération après panne au niveau de l'instance dans la même région
|
Centre de configuration, synchronisation des messages et traitement idempotent
|
Ne remplace pas la reprise après sinistre interrégionale
| |
Primaire-standby interrégional
|
Charges de travail nécessitant une protection contre les pannes au niveau de la région
|
Instances interrégionales, routage des messages et conditions de RTO/RPO et de retour arrière définies
|
Aucun basculement transparent par défaut
| |
Actif-actif
|
Charges de travail disposant de traitements idempotents, de déduplication et de résolution de conflits matures
|
ID de message globaux, stratégies de déduplication et de résolution de conflits
|
Déconseillé comme solution par défaut
|
Solution de ligne de base à instance unique
Cette solution s'applique aux chemins non critiques, aux charges de travail pouvant tolérer une courte indisponibilité et aux scénarios avec des exigences RTO et RPO souples.
Considérations de conception clés
Sur la base des types d'instances et des limites, sélectionnez une spécification d'instance qui répond à vos besoins métier en matière de TPS, de Queues, de Connections, de taille de message et de période de rétention.
Activez la reconnexion automatique de la Connection sur le client et assurez-vous que le client dispose de capacités de reconstruction de Channel et de récupération des consommateurs.
Établissez plusieurs AMQP Connections persistantes par instance d'application en fonction de la concurrence métier et répartissez le trafic de production et de consommation via un pool de connexions. Ne faites pas transiter tout le trafic sur une seule Connection puis augmentez uniquement le nombre de Channels.
Configurez Publisher Confirm, ACK des consommateurs, retry avec délai d'expiration, dead letter queues et alertes.
Effectuez les mises à niveau de version de l'instance comme requis par la politique officielle de gestion des versions et les notifications de mise à niveau. N'exécutez pas de versions expirées ou en fin de maintenance pendant de longues périodes.
Configurez des alertes pour les métriques clés, notamment le nombre de connexions, le débit d'envoi et de consommation, les codes d'erreur, l'accumulation dans les Queues, la latence de consommation et la limitation, sur la base de la surveillance et des alertes.
Risques et limitations
Une solution à instance unique fournit uniquement le SLA du produit correspondant au type d'instance, ce qui n'équivaut pas à une disponibilité côté métier à 100 %.
Si votre activité ne peut pas tolérer la fenêtre de panne d'une instance unique, passez à une solution de reprise après sinistre multi-instances.
Solution de standby double instance dans la même région
Cette solution s'applique aux charges de travail principales qui doivent améliorer la récupération après panne au niveau de l'instance dans la même région, mais ne nécessitent pas de reprise après sinistre interrégionale.
Vue d'ensemble de l'architecture
Considérations de conception clés
Achetez deux instances RabbitMQ dans la même région. Une configuration double instance dans la même région ne remplace pas la reprise après sinistre interrégionale.
Maintenez le Vhost, l'Exchange, la Queue, le Binding, les autorisations de compte et les politiques d'accès réseau des instances primaire et de standby fonctionnellement équivalents. (Recommandé) Gérez les ressources via une configuration automatisée ou des déclarations au démarrage de l'application pour éviter la dérive de configuration. Gérez les identifiants des instances primaire et de standby séparément et faites-les tourner conformément à votre politique de sécurité.
-
Options de synchronisation des messages :
Double écriture applicative — Le producteur écrit simultanément dans les instances primaire et de standby. La double écriture applicative peut réduire les écarts de données dus aux échecs d'écriture sur un chemin unique, mais ne fournit pas de garanties d'atomicité inter-instances. Gérez les succès partiels, l'expiration du délai de confirmation, la retry idempotente et la compensation.
Routage global des messages — Utilisez le routage global des messages pour transférer de manière asynchrone les messages d'une Queue source sur l'instance primaire vers une Queue ou un Exchange sur l'instance de standby. Cette méthode présente une latence de synchronisation, et le RPO dépend de l'accumulation du routage et des conditions réseau. La prise en charge des fonctionnalités dépend de la description du type d'instance et de la console.
Le routage global des messages consomme depuis la Queue source et transfère les messages vers la cible. Il ne s'agit pas d'une réplication sidecar de la Queue source. Ne réutilisez pas directement une Queue activement consommée par les consommateurs métier comme source de routage. Liez l'Exchange source à la fois à une Queue métier et à une Queue de synchronisation de reprise après sinistre dédiée, et utilisez la Queue dédiée comme source de routage. Pour les sémantiques, consultez le routage global des messages et RabbitMQ Shovel.
Si le type de cible du routage global des messages est défini sur Exchange, vérifiez que l'Exchange cible possède des Queues liées capables de stocker des messages. Sinon, les messages routés vers l'Exchange peuvent être perdus si aucune Queue n'est disponible pour les recevoir.
Par défaut, les consommateurs consomment uniquement depuis l'instance primaire. Lors du basculement, démarrez ou augmentez l'échelle des consommateurs sur l'instance de standby et empêchez les instances primaire et de standby de consommer simultanément le même flux métier pour éviter les effets secondaires en double.
Mettez en œuvre un traitement idempotent par ID de message métier, permettant une livraison en double ou compensatoire après le basculement.
Procédure de basculement recommandée
Confirmez via la surveillance que l'instance primaire est indisponible ou rencontre des anomalies de performance affectant les opérations d'envoi ou de consommation métier et ne s'est pas rétablie dans la fenêtre attendue.
Suspendez, limitez ou dégradez les écritures côté production conformément à votre plan d'urgence métier pour empêcher l'élargissement de l'écart de données entre l'instance primaire et celle de standby pendant la fenêtre de panne.
Basculez vers l'instance de standby via le centre de configuration ou la configuration de l'adresse d'accès de l'application. Si vous utilisez un DNS géré par le client, vérifiez que la mise en cache DNS et la vérification TLS ne bloquent pas le basculement.
Démarrez les consommateurs sur l'instance de standby ou augmentez le poids de consommation de l'instance de standby.
Surveillez le taux de réussite d'envoi, le taux de consommation, l'accumulation dans les Queues et le taux de réussite métier.
Après la récupération de l'instance primaire, effectuez la réconciliation, la compensation et la déduplication en fonction des enregistrements d'envoi et de consommation métier, des métriques d'accumulation et des IDs de message métier avant de revenir en arrière via un processus de changement contrôlé.
Solution de reprise après sinistre primaire-standby interrégionale
Cette solution s'applique aux charges de travail principales qui doivent se protéger contre les pannes au niveau de la région, ou aux charges de travail naturellement déployées sur plusieurs régions.
Vue d'ensemble de l'architecture
Considérations de conception clés
Créez des instances RabbitMQ dans deux régions distinctes. Maintenez la topologie, les autorisations de compte et les politiques d'accès réseau fonctionnellement équivalentes. Gérez les identifiants séparément pour chaque instance.
Utilisez le routage global des messages, la double écriture applicative ou un mécanisme Outbox métier pour synchroniser les messages critiques. La prise en charge des fonctionnalités pour le routage global des messages dépend de la description du type d'instance et de la console.
Lors de l'utilisation du routage global des messages, appliquez la même conception de Queue de synchronisation de reprise après sinistre dédiée que pour la solution dans la même région afin d'éviter la compétition avec les consommateurs métier pour la Queue source.
Si le type de cible du routage global des messages est défini sur Exchange, vérifiez que l'Exchange cible possède des Queues liées capables de stocker des messages.
Lors de l'utilisation du routage global des messages, évaluez les coûts d'EventBridge et de Cloud Enterprise Network (CEN), la latence de synchronisation des messages et l'accumulation du routage. Lors de l'utilisation de la double écriture applicative ou d'Outbox, planifiez séparément la mise en réseau du client, les points d'accès, les listes d'autorisation, les coûts de liaison et l'approche de basculement.
La limite de taille de message sur la cible doit être supérieure ou égale à celle de la source. Les messages dépassant la limite cible peuvent échouer lors du routage.
Le routage global des messages ne prend pas en charge le routage transitif. Un routage de A vers B vers C ne transfère pas automatiquement les messages de A via B vers C. Si vous avez besoin d'un routage de A vers C, configurez un routage direct de A vers C.
La reprise après sinistre interrégionale ne doit pas supposer un basculement entièrement transparent par défaut. Définissez clairement le RTO, le RPO, les approbateurs de basculement, les conditions de retour arrière et le mécanisme de compensation des données.
Solution actif-actif
Cette solution s'applique aux charges de travail disposant déjà de solides capacités de traitement idempotent, de déduplication, de résolution de conflits et de cohérence à terme, et où les deux régions ou instances doivent traiter simultanément le trafic. L'actif-actif est une conception d'architecture d'application cliente et ne signifie pas que le produit fournit automatiquement des capacités actif-actif inter-instances ou de cohérence globale.
Considérations de conception clés
Le producteur doit utiliser des IDs de message métier globalement uniques qui restent stables lors des retries.
Le consommateur doit mettre en œuvre un traitement idempotent et une déduplication par clé primaire métier. Ne vous fiez pas au compteur de livraison RabbitMQ comme seule source de vérité.
Définissez clairement le chemin d'écriture principal et la direction de synchronisation pour chaque message afin d'éviter les boucles de synchronisation bidirectionnelles ou l'amplification de la duplication.
Définissez clairement les limites de sémantique d'ordre. L'actif-actif inter-instances ne fournit généralement pas de garanties d'ordre strictes globales.
Définissez clairement les stratégies de résolution de conflits, y compris les paiements en double, les commandes en double, les déductions de stock et autres effets secondaires métier.
Maintenez des capacités de test de simulation continues et de réconciliation automatisée.
Risques et limitations
L'actif-actif n'est pas recommandé comme solution par défaut. La plupart des charges de travail devraient privilégier le primaire-standby ou la dégradation par paliers pour éviter la dégradation de la stabilité causée par la complexité.
Tests de simulation et critères d'acceptation
Avant de lancer une solution de reprise après sinistre multi-instances, effectuez au moins les tests de simulation suivants :
|**Élément de test**
|
**Objectif de vérification**
| | --- | --- | |
Échec d'accès à l'instance primaire
|
Le client bascule vers l'instance de standby comme prévu. Le RTO atteint l'objectif.
| |
Échec d'envoi de l'instance primaire
|
Le producteur identifie les échecs et effectue des retries ou des compensations sans duplication incontrôlée.
| |
Distribution multi-connexions
|
Les instances d'application établissent plusieurs Connections persistantes comme configuré. Après un redémarrage ou un basculement, le pool de connexions se rétablit et le trafic ne reste pas concentré sur une seule Connection.
| |
Redémarrage du consommateur
|
L'application reconstruit les Channels et rétablit les abonnements des consommateurs.
| |
Latence du routage global des messages
|
L'accumulation de la Queue source dédiée, l'afflux cible et la latence de synchronisation sont observables.
| |
Prise en charge de la consommation par l'instance de standby
|
Les consommateurs de l'instance de standby traitent les messages existants après le démarrage. L'idempotence métier est effective.
| |
Retour à l'instance primaire
|
La réconciliation métier, la compensation, la déduplication et le retour progressif réussissent.
|
Les métriques suivantes définissent les critères d'acceptation de votre solution de reprise après sinistre :
RTO — Temps écoulé entre le moment où l'activité est affectée ou où les conditions de basculement sont remplies et la récupération de l'activité.
RPO — Plage maximale de messages qui peuvent être perdus ou nécessiter une compensation pendant la fenêtre de panne.
Taux de duplication — Pourcentage de messages en double lors du basculement et de la relecture et leur impact métier.
Temps de récupération de l'accumulation — Temps nécessaire pour que l'accumulation dans les Queues revienne à des niveaux normaux après le basculement.
Taux de réussite de la récupération du client — Taux de réussite de la reconnexion de la Connection, de la reconstruction de Channel et du réabonnement des consommateurs.
Distribution des connexions — Après le redémarrage, la montée en puissance ou le basculement de l'application, le trafic de production et de consommation continue d'être réparti sur plusieurs Connections persistantes. Évitez l'utilisation à long terme d'une seule Connection.