Top Rated ZeroMQ Alternatives
Nothing, really, absolutely nothing. 0MQ is a developer bait. Review collected by and hosted on G2.com.
At the first sight, 0MQ looks like developers dream. Small, well contained, nicely encapsulated, brokerless messaging library. The issue is that 0MQ is poorly designed. Unclear and inefficient threading model with bottlenecks, difficult to provide message level security which would be acceptable for security savvy customers and its abstractions are difficult to understand and use for common engineers.
I am aware of at least 3 different projects in 3 different companies, which adopted 0MQ and then spent months / years trying to get rid of it. Everything looks nice in the development / test environment, but once you hit productions, things start to go south. Review collected by and hosted on G2.com.
21 out of 22 Total Reviews for ZeroMQ
Overall Review Sentiment for ZeroMQ
Log in to view review sentiment.
You can really design the pattern which bests fits your needs. Whether you need PUB-SUB or a broker, you can build tools tailored on your needs, knowing that you will always be able to modify and add new features as desired.
Available for a large number of programming languages.
Documentation is extensive and examples are provided for the various languages.
The CURVE mechanism ensures secure authentication and confidentiality, making ZeroMQ a good choice also for IoT or other applications requiring communication over the internet.
The community is large and active. Review collected by and hosted on G2.com.
Designing your own tools may be complicated, and if one is looking to solve a very common problem, choosing a tool to solve the specific task could be the better choice.
https://learning-0mq-with-pyzmq.readthedocs.io/en/latest/ Review collected by and hosted on G2.com.
What I liked about ZeroMQ the most is that it is very easy to use. We had at the same project two queue implementations: ZeroMQ and Kafka. Kafka was for heavy loaded installations and ZeroMQ for the rest. And ZeroMQ had only one configuration class that created a ZSocket bean, that's it. Now you just use "zmqPublisher.send" to push your message into the queue.
For comparison Kafka had 15 classes and interfaces for configuration a publisher.
The same with the subscriber. Review collected by and hosted on G2.com.
ZeroMQ has a limit on messages. Once the limit reached, it doesn't accept any new messages. And also it doesn't support topics. So if you're using several kinds of devices, you need to encode their type inside the message. Review collected by and hosted on G2.com.
I like the ZMQ concept of being "lego" of various socket type, which could be connected to each other, e.g Publisher - Subscriber,
Router - Dealer, Request - Reply etc.
For example when I needed to provide distributed logging my application I just used Publisher - Subscriber socket types, so multiple publishers sent their logs to one subscriber which stored them.
And Router - Dealer model is great to send messages to specific clients and get response from them when the work is done.
ZMQ allows socket sharing for threads and processes as well, which provides ability do build multithreaded or multiprocess application.
Also ZMQ API is available for any modern programming language so can be easily installed and integrated.
And of course, speed. I tested my ZMQ application under intensive stress on 40 machines and it keep doing pretty well, no stuck or lost messages and no crashes, so when it comets to reliability ZMQ is the right choice. Review collected by and hosted on G2.com.
I think the only thing that can push people away is the same thing I liked most :) - being "lego"
You have to construct and configure your sockets properly to get any working result, which means invest some time in learning ZMQ concept and code examples.
Socket types is something you have to dig into, while with PUB-SUB examples its all seems very simple, more complicated constructions will demand deep understanding of ZMQ protocol and socket types, which could be steep learning curve for newcomers Review collected by and hosted on G2.com.
In my past managing to software development of the 25-th in size Forex bureau we were challenged to receive upto 400 MB/s stock tickets. We failed to increase the socket performance with .Net remoting. Searching for a robust yet easy to use solution we came across ZeroMQ. It had elegant, simple yet powerful design. It's pub/sub model was exactly what we needed. With some fine tuning we manage to process upto 5 million messages per second on a consistent flow of tickets with high water mark threshold of 500K. We were encoding the forex pair in the first bits of each message and that was super efficient. We managed even to make Level 1/2 share trading work with pub/sub channel headers. ZeroMQ was 2 hours of training and you are already having first results. Compared to my previous experiences with IBM Web Sphere MQ Series, AMQ, MSMQ, ZMQ was just outperforming both in ease of adoption and performance. Review collected by and hosted on G2.com.
Windows features and performance were a bit limited. Sometimes we had to use TCP where InProc would have been better due to lack of support on Windows. Review collected by and hosted on G2.com.
The documentation is good and it is easy to get started with it. Review collected by and hosted on G2.com.
Sometimes it is a bit hard to work out how the queueing of messages works (when one side is down), and you have to implement TTL (time to live) functionality yourself. Review collected by and hosted on G2.com.
ZMQ has good documentation and there is a wide array of wrappers for different languages.
It is ideal for high performance responsive messaging across different platforms and technologies.
I personally used it to send low latency messages between an embodied Linux (c++) machine and a windows computer (c#).
It also has a wide array of implementations so legacy systems can communicate with newer systems. Review collected by and hosted on G2.com.
There are some limitations on the type of data you can sent. While there is an option to send raw bitstreams it is not easy or fun to use. It is better for strings and information that can be easily serialized. Review collected by and hosted on G2.com.
It's fast. Have high throughput compared to others. Review collected by and hosted on G2.com.
Not proper built-in method to know if the component to which we are communicating is alive or not. If it's dead then zmq silently drop messages. Review collected by and hosted on G2.com.
Lightweight and best for high throughput and low latency systems Review collected by and hosted on G2.com.
Not very eash to implement as to write a lot of code to take care of sockets and so. Review collected by and hosted on G2.com.
The setup is easy so you can quickly get network communications operational. Review collected by and hosted on G2.com.
It is not always obvious to know how things are handled behind the scenes. Review collected by and hosted on G2.com.
