Pros and Cons of Publish-Subscribe
ÃMQâs low-level patterns have their different characters. Pub-sub addresses an old messaging problem, which is multicast or group messaging. It has that unique mix of meticulous simplicity and brutal indifference that characterizes ÃMQ. Itâs worth understanding the trade-offs that pub-sub makes, how these benefit us, and how we can work around them if needed.
First, PUB sends each message to âall of many,â whereas PUSH and DEALER rotate messages to âone of many.â You cannot simply replace PUSH with PUB or vice versa and hope that things will work. This bears repeating, because people seem to quite often suggest doing this.
More profoundly, pub-sub is aimed at scalability. This means large volumes of data, sent rapidly to many recipients. If you need millions of messages per second sent to thousands of points, youâll appreciate pub-sub a lot more than if you need a few messages a second sent to a handful of recipients.
To get scalability, pub-sub uses the same trick as push-pull, which is to get rid of back-chatter. This means that recipients donât talk back to senders. There are some exceptionsâe.g., SUB sockets will send subscriptions to PUB socketsâbut this is anonymous and infrequent.
Killing back-chatter is essential to real scalability. With pub-sub, itâs how the pattern can map cleanly to the Pragmatic General Multicast (PGM) protocol, which is handled by the network switch. In other words, subscribers donât connect ...
Get ZeroMQ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.