Questions fréquentes

Questions générales

Pub/Sub est-il lié à Firebase Cloud Messaging (FCM) ou à la solution Google Cloud Messaging (GCM) obsolète ?

Oui et non. Ces systèmes sont tous deux utilisés pour distribuer des messages. FCM permet d'envoyer des messages depuis et vers les appareils des utilisateurs finaux, tandis que Pub/Sub sert à communiquer entre les serveurs. FCM est conçu pour s'adapter à un très grand nombre de points de terminaison de distribution, mais son débit (nombre de messages par seconde et par canal) est faible. Pub/Sub n'a pas de limite de débit et dispose d'une API plus générique.

Le produit est-il associé à PubSubHubbub ?

Non. Même si les Googleurs ont travaillé en étroite collaboration sur la création de PubSubHubbub, ses atouts en matière de RSS et de syndication de contenu ne constituent généralement pas des cas d'utilisation que Pub/Sub est conçu pour traiter. Hormis le nom, ils ont très peu de choses en commun.

Puis-je me servir de Pub/Sub pour communiquer entre différents modules App Engine ?

Oui. Vous pouvez vous servir de Pub/Sub pour envoyer et recevoir des messages entre différents modules d'une application App Engine, et même entre différentes applications au sein d'un même projet, sans configuration particulière de la liste de contrôle d'accès (LCA). Pour obtenir une publication à faible latence, mettez le client éditeur en cache en l'initiant comme variable globale.

Puis-je utiliser Pub/Sub avec d'autres plates-formes qu'App Engine ?

Oui. Vous pouvez utiliser Pub/Sub avec des applications hébergées sur Google Compute Engine, ou même sur des plates-formes n'appartenant pas à Google. Vous avez seulement besoin d'un projet Google Cloud Console pour commencer. Pour obtenir une publication à faible latence, pensez à mettre en cache le client éditeur en le rendant global.

Comment connecter des applications App Engine et Compute Engine ?

Utilisez la distribution push afin de bénéficier d'une messagerie à faible latence depuis Compute Engine vers App Engine. Choisissez la distribution pull pour envoyer des données depuis App Engine vers un grand nombre d'abonnés Compute Engine.

Comment surveiller les métriques de Pub/Sub ?

Pour savoir comment surveiller ces métriques, consultez cet article.

Pub/Sub est-il intégré à Cloud KMS ?

Oui. Les sujets Pub/Sub peuvent être configurés pour protéger le contenu des messages à l'aide d'une clé dans Cloud KMS. Pour en savoir plus, consultez la section Utiliser des clés de chiffrement gérées par le client.

Questions techniques

Les messages sont-ils distribués dans l'ordre ?

Pub/Sub ne garantit pas que la distribution des messages s'effectue dans l'ordre ni dans l'ordre FIFO (premier entré, premier sorti). Les messages sont distribués aussi rapidement que possible, la préférence étant donnée en premier aux messages les plus anciens. Cette priorité n'est toutefois pas certifiée. Un ordonnancement strict irait à l'encontre des garanties de disponibilité et d'évolutivité de Pub/Sub. Pour en savoir plus sur ce sujet, consultez la page Ordonnancement des messages.

Pourquoi est-ce que je reçois des messages d'erreur de quota, alors que mon utilisation est bien inférieure aux limites fixées ?

Les quotas sont appliqués au projet associé au client authentifié, comme expliqué sur la page intitulée Quotas et limites. Assurez-vous d'utiliser un compte de service ou une valeur API_KEY associés à un projet disposant de quotas suffisants. La ligne de commande gcloud en particulier se sert d'un projet partagé, et les quotas associés sont donc très limités.

Pourquoi le nombre de messages en double est-il trop important ?

Pub/Sub garantit au moins une distribution de chaque message. Des doubles occasionnels sont donc inévitables. Toutefois, un taux élevé de doubles peut indiquer que le client n'accuse pas réception des messages dans le délai ack_deadline_seconds et que Pub/Sub tente de distribuer à nouveau ces messages. Cette situation peut être observée dans les métriques de surveillance pubsub.googleapis.com/subscription/pull_ack_message_operation_count pour les abonnements pull et pubsub.googleapis.com/subscription/push_request_count pour les abonnements push. Recherchez des valeurs expired ou webhook_timeout élevées dans le code de réponse /response_code. La probabilité de trouver ces valeurs élevées est particulièrement importante s'il y a beaucoup de petits messages, car Pub/Sub peut traiter les messages par lot en interne et un lot dont l'état est partiellement confirmé sera entièrement redistribué.

Il est également possible que l'abonné n'accuse pas réception de certains messages, car le chemin d'accès au code qui traite ces messages échoue et l'appel Acknowledge n'est jamais effectué, ou que le point de terminaison push ne transmette jamais de réponse ou renvoie une erreur.

Comment détecter les messages en double ?

Cloud Pub/Sub attribue à chaque message un identifiant "message_id" unique, qui peut servir à détecter les messages en double reçus par l'abonné. Toutefois, cet identifiant ne vous permettra pas de détecter les doubles créés par plusieurs requêtes de publication concernant les mêmes données. Pour que vous puissiez détecter ces doubles, un identifiant unique devra être fourni par l'éditeur pour chaque message concerné. Pour en savoir plus, consultez la page E/S de Pub/Sub.