Does Google Pub/Sub queue or topic?

Question

I am familiar with JMS and novice with Google Pub/Sub.

In JMS there are 2 options:

• Queue: only one consumer can accept message.
• Topic: each consumer accepts each message from the topic

I believe that Google Pub/Sub should support something like this, but a quick Googling didn't help me to answer that question.

Please point me out to the corresponding documentation part.

Answer 1

As the name "Pub/Sub" indicates, Google Pub/Sub supports publish/subscribes semantics which correspond to JMS topics. It doesn't support point-to-point semantics which correspond to JMS queues, at least not directly.

You can see an overview of the semantics in the documentation. The "Publisher-subscriber relationships" section may be helpful. To be clear, this documentation does use the word queue in two places:

1. In the "Pub/Sub message flow" section: "When a message is acknowledged by the subscriber, it is removed from the subscription's message queue."
2. In the "Common use cases" section: "For example, a large queue of tasks can be efficiently distributed among multiple workers, such as Google Compute Engine instances."

The term queue here is being used to refer to the actual subscription on the topic (i.e. where the messages are placed for subscribers to consume). Furthermore, the architectural overview includes this diagram: This diagram demonstrates how multiple subscribers can receive messages from the same subscription (e.g. for balancing workloads). This would be akin to the "shared subscription" functionality added for topics in JMS 2.

Answer 2

I was looking for the answer to this question, and I've found this documentation that describe the behaviour of a queue rather than a topic :

https://cloud.google.com/pubsub/docs/subscriber

While a message is outstanding to a subscriber, however, Pub/Sub tries not to deliver it to any other subscriber on the same subscription.

So my understanding is that if you want

• a topic behaviour (one to many): you create many subscriptions, each will get a copy of the message

• a queue behaviour : you create one subscription

Then on each subscription you can run one or more subscribers for load balancing, each message is delivered to only one subscriber

I didn't see what kind of distribution among subscribers of a subscription. likely to be round robin.