Basically Pub/sub is shorthand for publish/subscribe messaging, an asynchronous communication method in which messages are exchanged between applications without knowing the identity of the sender or recipient.
Basic Concept of pub/sub:
Four core concepts make up the pub/sub model:
- Topic – An intermediary channel that maintains a list of subscribers to relay messages to that are received from publishers
- Message – Serialized messages sent to a topic by a publisher which has no knowledge of the subscribers
- Publisher – The application that publishes a message to a topic
- Subscriber – An application that registers itself with the desired topic in order to receive the appropriate messages
How Pub/Sub Works
In the overview we covered how a publisher sends a message to a topic and how the topic forwards the message to the appropriate subscriber. From a topology point of view it is a simple process.
When it comes to coding the publish or the subscribe process the model can be a bit more confusing. Consider the following Java code which is used to create a topic.
Topic createTopic(String topicName) throws IOException {
String topic = getTopic(topicName); // adds project name and resource type
Pubsub.Projects.Topics topics = pubsub.projects().topics();
ListTopicsResponse list = topics.list(project).execute();
if (list.getTopics() == null || !list.getTopics().contains(new Topic().setName(topic))) {
return topics.create(topic, new Topic()).execute();
} else {
return new Topic().setName(topic);
}
}
Cloud or edge providers often simplify this code. Google Cloud, for example, has simplified topic creation into a single line of code.
gcloud beta pubsub topics create topicNameExamples of Pub/Sub
Publish/subscribe messaging has a multitude of use cases, some of which include:
- Balancing workloads
- Asynchronous workflows
- Event notifications
- Data streaming
Advantages and disadvantages of pub/sub
As with all technology, using pub/sub messaging comes with advantages and disadvantages. The two primary advantages are loose coupling and scalability.
Loose coupling
Publishers are never aware of the existence of subscribers so that both systems can operate independently of each other. This methodology removes service dependencies that are present in traditional coupling. For example, a client generally cannot send a message to a server if the server process is not running. With pub/sub, the client is no longer concerned whether or not processes are running on the server.
Scalability
Pub/sub messaging can scale to volumes beyond the capability of a single traditional data center. This level of scalability is primarily due to parallel operations, message caching, tree-based routing, and multiple other features built into the pub/sub model.
Scalability does have a limit though. Increasing the number of nodes and messages also increases the chances of experiencing a load surge or slowdown. On top of that, the advantages of the pub/sub model can sometimes be overshadowed by the message delivery issues it experiences, such as:
- A publisher may only deliver messages for a certain period of time regardless of whether the message was received or not.
- Since the publisher does not have a window into the subscriber it will always assume that the appropriate subscriber is listening. If the subscriber isn’t listening and misses an important message it can be disastrous for production systems.
Key Points
- Publish/subscribe messaging is when a publisher sends a message to a topic and the message is forwarded to a subscriber.
- The concept of pub/sub is easy to understand but every coding and programming language handles it differently, making it a little more challenging to learn across all platforms.
- On the edge, message delivery times can be two to four times faster by using a network backbone and multiple points of presence.
Comments
Post a Comment