How does Google Cloud Pub/Sub deal with multiple App Engine instances

2
votes

Reading this page, https://cloud.google.com/appengine/docs/flexible/nodejs/writing-and-responding-to-pub-sub-messages, I see that pub/sub sends a message to a url you provide when there is a new message.

The reason I wanted to use pub/sub was to connect my App Engine instances together (if App Engine scales to multiple servers, I want the servers to know some of the same information). With the use of Google Cloud Pub/Sub, will all of my App Engine instances get the message, or will only one instance get the message and is there a way to make sure all of the instances get the same message?

I also checked into Pull, https://cloud.google.com/pubsub/docs/pull, and it sounds like it would work, but I don't understand how the messages are pushed without using a URL endpoint.

1
google-cloud-platformgoogle-cloud-pubsub
what do you mean you want them to have the same information? this sound like it might be a use case for the cache service (they used to have memcache available, now I think it's redis backed MemoryStore) available to app engine instances. pub / sub is for when you want servers to perform some action in response to some kind of event. what're the details of the use case – bryan60
A chat service that needs to know about a new message on one of its servers to send a message from all of its servers to connected clients. Frequently querying a database seems expensive. MemoryStore might do the job if Pub/Sub doesn't work for this application. – JVE999
kind of depends how this is implemented. is it using web sockets or are connected clients polling the backend? if polling, memorystore is the tool for the job. if websockets, depends on what websocket framework you're using. socket.io has horizontal scaling built into it, as do many others. I think app engine's pusher service might be what you're after if you want to make use of services available to app engine. in any event, i don't think pub / sub is the tool you're after. – bryan60
I'm using websockets with socket.io, so, at first, it seems that socket.io's horizontal scaling would be ideal, but I don't see a way to make it work with App Engine. I think perhaps I can use MemoryStore and query the information frequently. I'd still be querying frequently, but it appears that using MemoryStore would be significantly cheaper than querying a database. – JVE999
been a while since i horizontally scaled a socket io server, so i needed a refresher. it does rely on a central pub / sub service, and the one socket.io provides requires a redis instance and relies on redis's pub / sub functionality. so you might be abel to use memory store if they expose that redis functionality, but im not sure, otherwise you may need to write or look into custom adapters for app engine pub sub – bryan60

1 Answers

0
votes

PubSub has two mechanisms to deliver a message:

  • Push Subscriber. PubSub delivers automatically to an endpoint a message as soon as it arrives, as explained in the documentation you already checked.

  • Pull Subscriber. PubSub delivers messages to a Subscriber after a pull request was explicitly performed. You can even have more than one Subscriber pulling the messages. Pulling means a client application connects to a specific subscription and requests for messages.

Both approaches can work for your chat use case, let me address it with the following approach:

1. Not acknowledge the messages.

The scope of PubSub is deliver the messages at least once. This means that as soon as an AppEngine instance reads the message and acknowledge it, such message will be removed from PubSub. Your instances can read the messages and don't ack it, in this way PubSub can retry the delivery (the messages will remain in PubSub for a default retention period of 7 days.

At certain point all the instances will have to read the same message; but you would need to implement a mechanism to identify the messages that were already read to prevent duplicates, this could be not the best solution.

2. Integrate a Publisher application, and every new chat message can be Published to Pubsub.

You would need to have a Publisher on each server your chat application depends on. All your servers (instances) would have a client that publish a message as soon as it arrives. Once received, the goal of pubsub is to deliver each message at least once; so, you would need to have an different application called Subscriber (Push or Pull) that read these messages and its responsibility is to send each message to all of your servers (please note that even when they can be the same instances, another process have to have the role of Subscriber).

Once the Subscriber sends the message to all the servers, the message can be acked and removed from PubSub. As you can have several subscribers you still would need to deal with duplicates to prevent your clients receive twice the same message