ApsaraMQ for RocketMQ:SDK HTTP ApsaraMQ for RocketMQ (plusieurs langages recommandés)

Prise en charge de plusieurs langages de programmation

Notes d'utilisation

• Les consommateurs HTTP peuvent utiliser le scrutin long (long polling) ou le scrutin court (short polling) pour consommer les messages depuis les brokers ApsaraMQ for RocketMQ.

  • Scrutin long : le consommateur envoie une requête au broker pour obtenir des messages d'un topic spécifique. Si aucun message n'est disponible, le broker maintient la requête ouverte jusqu'à la production d'un message ou l'expiration du délai de scrutin long.

  • Scrutin court : si aucun message n'est disponible, le broker renvoie immédiatement une réponse. Le client envoie alors de nouvelles requêtes d'abonnement de manière répétée.

  Configurez le mode de scrutin comme suit :

  • Scrutin long : définissez le paramètre waitSeconds sur une valeur supérieure à 0 dans la requête d'abonnement. La valeur maximale est de 30 secondes.

  • Scrutin court : définissez le paramètre waitSeconds sur 0 ou ne le spécifiez pas dans la requête d'abonnement.

  Pour plus d'informations, consultez la rubrique Consommer des messages.

  Le scrutin court en l'absence de messages dans le topic génère un grand nombre de requêtes invalides, qui entraînent des frais d'appel d'API. Pour réduire ces requêtes inutiles et optimiser les coûts, privilégiez le scrutin long et augmentez le temps d'attente. Pour comprendre le calcul des frais d'appel d'API, consultez la rubrique Frais d'appel d'API.

  Important

  Si plus de 100 consommateurs se connectent à une instance ApsaraMQ for RocketMQ via HTTP, le système bascule automatiquement du scrutin long vers le scrutin court afin de garantir la stabilité du service et la rapidité de la consommation. Pour éviter une augmentation des coûts liée aux requêtes invalides après ce basculement, limitez le nombre de connexions de consommateurs.

• L'accès via le SDK HTTP est une fonctionnalité avancée d'ApsaraMQ for RocketMQ. Les clusters Apache RocketMQ autogérés ne prennent pas en charge cette fonctionnalité.

• Assurez-vous que les ressources auxquelles vous souhaitez accéder se trouvent dans la même région que l'endpoint HTTP utilisé.

  Par exemple, si votre instance ApsaraMQ for RocketMQ se trouve dans la région Chine (Hangzhou), vous devez utiliser l'endpoint de la région Chine (Hangzhou). Tenez compte des points suivants :

  • Si votre client se trouve dans la région Chine (Hangzhou), utilisez l'endpoint interne HTTP pour des performances optimales.

  • Si votre client se trouve en dehors de la région Chine (Hangzhou), assurez-vous de la connectivité Internet et utilisez l'endpoint public HTTP.

• Les messages peuvent être transmis entre les clients TCP et HTTP. Étant donné que HTTP utilise la sérialisation XML, les attributs, corps, tags et clés des messages doivent respecter les règles XML.

  Remarque

  Pour plus d'informations sur les règles XML, consultez la page Syntaxe XML. Vous pouvez également utiliser l'outil Validateur XML pour vérifier la conformité.

  Les caractères non conformes aux règles XML provoquent les problèmes suivants :

  • L'envoi des messages via HTTP échoue.

  • La consommation des messages envoyés via TCP et consommés via HTTP échoue.

  Pour gérer les messages contenant des caractères non conformes, utilisez l'encodage et le décodage Base64.