Lorsque vos activités s'étendent sur plusieurs régions, la synchronisation des messages et de la progression des consommateurs entre les instances ApsaraMQ for RocketMQ nécessite la création et la maintenance de pipelines de réplication personnalisés. Global Replicator élimine cette charge en fournissant une réplication de messages inter-régions intégrée avec une latence de l'ordre de la seconde. Il prend en charge la reprise après sinistre géographique, la redondance géographique active et l'agrégation centralisée des données. Global Replicator est compatible avec ApsaraMQ for RocketMQ ainsi qu'avec les clusters Apache RocketMQ open source (version 4.4.0 ou ultérieure).
Données répliquées
| Type de données | Prise en charge |
|---|---|
| Messages normaux | Oui |
| Messages ordonnés | Oui |
| Messages planifiés ou différés | Oui |
| Messages transactionnels | Oui |
| Progression du consommateur (offsets) | Oui |
Global Replicator prend en charge la synchronisation unidirectionnelle et bidirectionnelle. Par défaut, la synchronisation bidirectionnelle empêche la réplication circulaire.
En cas d'erreur sur l'instance source, la fonctionnalité de synchronisation rapide renvoie la progression du consommateur depuis le groupe de destination vers l'instance source, réduisant ainsi la consommation en double des messages.
Fonctionnement
Global Replicator réplique les messages de manière asynchrone via des connecteurs. Ces connecteurs passent à l'échelle en quelques secondes, appliquent des tags basés sur des règles aux messages et prennent en charge la reprise des transferts upload et download.
La connectivité réseau inter-régions entre les instances est gérée par Cloud Enterprise Network (CEN), assurant une synchronisation des messages avec une latence de l'ordre de la seconde.
Pendant la synchronisation, Global Replicator ajoute des tags à chaque message selon la clé et la valeur spécifiées dans les attributs utilisateur. Les applications consommatrices filtrent ces tags à l'aide de la méthode de filtrage SQL-92 pour décider si elles reçoivent toutes les données ou uniquement les données produites localement.
Global Replicator consomme des ressources de lecture et d'écriture sur les instances ApsaraMQ for RocketMQ concernées. Évaluez les spécifications de calcul de votre instance avant d'activer cette fonctionnalité.
Cas d'utilisation
Tous les clusters impliqués dans Global Replicator sont des instances indépendantes disposant de capacités complètes de lecture et d'écriture. Les messages sont répliqués de manière asynchrone entre eux.
Agrégation des données (unidirectionnelle)
Agrégez les messages provenant de plusieurs régions ou instances dans une région centrale pour un traitement unifié. Chaque unité métier traite les données sur le serveur le plus proche, évitant ainsi la latence transversale du réseau. La synchronisation unidirectionnelle réplique les données depuis des régions et instances distribuées — y compris les clusters Apache RocketMQ open source et ApsaraMQ for RocketMQ — vers un emplacement central unique.
Secteurs typiques : Banque, valeurs mobilières, assurance
Modèle d'architecture : Plusieurs unités, centre unique
Reprise après sinistre géographique (unidirectionnelle)
Maintenez une instance de secours dans une région secondaire, synchronisée via une réplication unidirectionnelle. En cas de panne du centre de données ou de la région principale, basculez le trafic vers l'instance de secours pour restaurer rapidement le service.
Secteurs typiques : Tous
Modèle d'architecture : Deux régions, deux centres de données
En fonctionnement normal, aucune application ne s'exécute dans la région secondaire, ce qui réduit la consommation de ressources et les coûts. Lors d'un basculement, démarrez les applications dans la région secondaire et utilisez la fonctionnalité de réinitialisation des offsets des consommateurs pour consommer un nombre minimal de messages historiques sur l'instance source.
Étant donné que la réplication est asynchrone, une petite quantité de données peut ne pas avoir atteint l'instance de secours au moment de la panne. Implémentez l'idempotence des messages dans votre logique métier pour gérer les éventuels doublons après le basculement.
Redondance géographique active (bidirectionnelle)
Déployez des applications simultanément dans plusieurs régions, la synchronisation bidirectionnelle maintenant les messages synchronisés sur toutes les instances actives. Les deux régions traitent le trafic de production en permanence, garantissant la continuité des activités si une région devient indisponible.
Secteurs typiques : Finance, énergie et autres industries où la continuité de service est critique
Modèle d'architecture : Deux régions, deux centres de données
Global Replicator ajoute automatiquement des tags aux messages synchronisés. Les applications productrices ne nécessitent aucune modification de code. Les applications consommatrices utilisent la méthode de filtrage SQL-92 pour sélectionner soit toutes les données, soit uniquement les données locales en fonction de ces tags.
Lors d'une panne régionale, les applications productrices acheminent tout le trafic vers l'instance saine. Ajustez les conditions de filtrage sur les applications consommatrices et utilisez la fonctionnalité de réinitialisation des offsets des consommateurs pour consommer les messages provenant d'autres régions avec un minimum de duplication. Concevez votre logique métier pour qu'elle soit idempotente afin que les messages en double n'affectent pas le traitement en aval.
Détails du taggage des messages
L'instance à laquelle une application se connecte est déterminée par l'endpoint configuré. Pendant la synchronisation, Global Replicator ajoute des tags à chaque message répliqué selon la clé et la valeur définies dans les attributs utilisateur. Les applications consommatrices utilisent ces tags pour contrôler si elles reçoivent toutes les données ou uniquement les données produites localement.
Pour plus de détails sur le comportement du taggage et la configuration des consommateurs, consultez Notes d'utilisation.
Avantages
Configuration low-code : Répliquez les messages entre les instances sans avoir à construire de pipelines de synchronisation personnalisés.
Configuration flexible : Mettez en place une synchronisation unidirectionnelle ou bidirectionnelle et utilisez le filtrage basé sur des tags pour une consommation sélective des messages.
Latence inter-régions de l'ordre de la seconde : S'appuyant sur EventBridge, Global Replicator offre une synchronisation de messages stable et à faible latence entre les régions.
Facturation
Global Replicator engendre des coûts liés à deux services :
EventBridge : Global Replicator utilise EventBridge pour la synchronisation des messages. Pour les détails tarifaires, consultez Facturation d'EventBridge.
ApsaraMQ for RocketMQ : La réplication consomme des ressources de lecture sur l'instance source et des ressources d'écriture sur l'instance de destination. Pour les détails tarifaires, consultez Facturation d'ApsaraMQ for RocketMQ.
Éditions, versions et régions prises en charge
Éditions et versions
| Édition / version | Synchronisation unidirectionnelle | Synchronisation bidirectionnelle |
|---|---|---|
| ApsaraMQ for RocketMQ 5.0 | Oui | Oui |
| ApsaraMQ for RocketMQ 4.0 (toutes les éditions sauf Standard) | Oui | Oui |
| ApsaraMQ for RocketMQ 4.0 (édition Standard) | Oui | Non |
| ApsaraMQ for RocketMQ Enterprise Platinum Edition avec clusters Apache RocketMQ (version 4.4.0 ou ultérieure) | Oui | Oui |
Global Replicator permet de synchroniser les données d'une instance ApsaraMQ for RocketMQ vers plusieurs instances de destination.