Frequently Asked Questions

General questions

Is Pub/Sub related to Firebase Cloud Messaging (FCM) or to the deprecated Google Cloud Messaging (GCM)?

Yes and no. These systems are each used to deliver messages, but FCM is used to deliver messages to and from end-user devices while Pub/Sub is used to communicate between servers. FCM is designed to scale to a very large number of delivery end points, but has low throughput (messages per second per channel). Pub/Sub does not have limits on throughput and has a more generic API.

Is this related to PubSubHubbub?

No. While Googlers were closely involved in originating PubSubHubbub, its strengths in RSS and content syndication generally are not use cases that Pub/Sub is designed to address. Aside from the name, they have very little in common.

Can I use Pub/Sub to communicate between different App Engine modules?

Yes. You can use Pub/Sub to send and receive messages between different modules in a App Engine application, and even between different applications in the same project, without any special ACL configuration. To achieve low latency publishing, cache the publisher client by initializing it as a global variable.

Can I use Pub/Sub with platforms other than App Engine?

Yes. You can use Pub/Sub with applications hosted on Google Compute Engine or even on non-Google platforms. All you need is a Google Cloud Console project to get started. For low latency publishing, consider caching the publisher client by making it global.

How can I connect App Engine and Compute Engine applications?

Use push delivery for low-latency messaging from Compute Engine to App Engine. Use pull delivery to send data from App Engine to large numbers of Compute Engine subscribers.

How can I monitor Pub/Sub metrics?

Please refer to this article.

Is Pub/Sub integrated with KMS?

Yes. Pub/Sub topics can be configured to protect message contents using a key in KMS. For more information, see Using customer-managed encryption keys.

Technical questions

Are messages delivered in order?

Pub/Sub does not guarantee in-order, or FIFO (first-in-first-out) delivery. Messages are delivered as fast as possible, with preference given to delivering older messages first, but this is not guaranteed. Strict ordering is at odds with Pub/Sub's availability and scalability guarantees; see Message Ordering for a detailed discussion of this topic.

Why am I getting quota errors when my usage is well below the limits?

Quotas are enforced against the project associated with the authenticated client, as explained in Quotas and Limits. Make sure that you are using a service account or API_KEY associated with a project that has sufficient quotas. The gcloud command line in particular uses a shared project, and the quotas are very limited.

Why are there too many duplicate messages?

Pub/Sub guarantees at-least-once message delivery, which means that occasional duplicates are to be expected. However, a high rate of duplicates may indicate that the client is not acknowledging messages within the configured ack_deadline_seconds, and Pub/Sub is retrying the message delivery. This can be observed in the monitoring metrics pubsub.googleapis.com/subscription/pull_ack_message_operation_count for pull subscriptions, and pubsub.googleapis.com/subscription/push_request_count for push subscriptions. Look for elevated expired or webhook_timeout values in the /response_code. This is particularly likely if there are many small messages, since Pub/Sub may batch messages internally and a partially acknowledged batch will be fully redelivered.

Another possibility is that the subscriber is not acknowledging some messages because the code path processing those specific messages fails, and the Acknowledge call is never made; or the push endpoint never responds or responds with an error.

How do I detect duplicate messages?

Pub/Sub assigns a unique `message_id` to each message, which can be used to detect duplicate messages received by the subscriber. This will not, however, allow you to detect duplicates resulting from multiple publish requests on the same data. Detecting those will require a unique message identifier to be provided by the publisher. See Pub/Sub I/O for further discussion.

Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...

Cloud Pub/Sub Documentation