Comparison of four message queues
Due to the increasing amount of data processing , the demand for message queues is also getting higher and higher. Here are several common message queues on the market.
It's the only thing in Microsoft's product that is considered valuable. This thing is not complicated, nothing but receiving and sending; it has some hard limits, like the maximum message size is 4MB. However, by connecting with some software like MassTransit or NServiceBus, it can completely solve these problems.
Introduction :
MicroSoft Message Queuing (Microsoft Message Queuing) is an asynchronous transmission mode that realizes mutual communication between multiple different applications. The applications that communicate with each other can be distributed on the same machine, or distributed in any connected network space. a location. Its implementation principle is: the sender of the message puts the information he wants to send into a container (we call it Message), and then saves it in a message queue (Message Queue) in a system public space; local or It is the remote message receiving program that takes out the message sent to it from the queue for processing.
Substance :
In the message passing mechanism, there are two more important concepts. One is a message and the other is a queue. The message is the information that needs to be transmitted by both parties of the communication, it can be various media, such as text, sound, image and so on. The final understanding of the message is negotiated in advance by both parties of the message transmission. The advantages of this are that one is equivalent to simply encrypting the data, and the other is that the use of a self-defined format can save the amount of communication. Messages can contain sender and receiver identifiers, so that only the specified user can see only the information delivered to him and return a receipt indicating whether the operation was successful. Messages can also contain timestamps to facilitate processing by the recipient for certain time-dependent applications. The message can also contain an expiration time, which indicates that if the message has not arrived within the specified time, it will be invalid. This is mainly used for applications that are closely related to time.
A message queue is a common storage space for sending and receiving messages, which can exist in memory or in physical files. Messages can be sent in two ways, express and recoverable. The difference between them is that express places messages in memory instead of physical disks for fast message delivery. In order to obtain higher processing power; in the recoverable mode, in each step of the transmission process, messages are written to the physical disk to obtain better failure recovery capabilities. The message queue can be placed on the machine where the sender and receiver are located, or it can be placed on another machine separately. It is precisely because of the flexibility of the placement method of the message queue that the reliability of the message transmission mechanism is formed. When the machine holding the message queue fails and is restarted, messages sent in recoverable mode can be restored to the state they were in before the failure, while messages sent by express are lost. On the other hand, using the message passing mechanism, the sender does not need to worry about whether the receiver is started, whether there is a failure or not. Or it may already be the next day when the transaction is actually completed.
Function :
The advantages of using MSMQ are: due to asynchronous communication, neither the sender nor the receiver can execute the rest of the code without waiting for the other party to return a successful message, thus greatly improving the ability of transaction processing; , the information sending mechanism has a certain function of failure recovery; MSMQ's message delivery mechanism makes it possible for both parties to have different physical platforms in message communication.
Using the MSMQ function provided by Microsoft's .net platform, you can easily create or delete message queues, send or receive messages, and even manage message queues.
*ActiveMQ.
The backbone of the Java world. It has a long history and is widely used. It is also cross-platform, providing a natural integration point of entry for products on non-Microsoft platforms. However, it is only possible to be considered if it has run over MSMQ.
Introduction :
ActiveMQ is the most popular and powerful open source message bus produced by Apache. ActiveMQ is a JMS Provider implementation that fully supports the JMS1.1 and J2EE 1.4 specifications. Although the JMS specification has been published for a long time, JMS still plays a special role in today's J2EE applications.
Expansion :
JMS:(http://baike.baidu.com/subview/157103/12665866.htm)
JMS is the Java Message Service ( Java Message Service) application program interface, which is an API for message -oriented middleware ( MOM) in the Java platform , which is used to send messages between two applications or in a distributed system for asynchronous communication. Java Message Service is a platform-independent API, and most MOM providers support JMS .
Feature list :
⒈ Write clients in multiple languages and protocols. Languages: Java, C, C++, C#, Ruby, Perl, Python, PHP. Application Protocol: OpenWire, Stomp REST, WS Notification, XMPP, AMQP
⒉ Fully supports JMS1.1 and J2EE 1.4 specifications (persistence, XA messages, transactions)
⒊ Support for Spring, ActiveMQ can be easily embedded into the system using Spring, and also supports the features of Spring 2.0
⒋ Passed the test of common J2EE servers (such as Geronimo, JBoss 4, GlassFish, WebLogic), and through the configuration of JCA 1.5 resource adaptors, ActiveMQ can be automatically deployed to any compatible J2EE 1.4 commercial server
⒌ Support multiple transmission protocols: in-VM, TCP, SSL, NIO, UDP, JGroups, JXTA
⒍ Support high-speed message persistence through JDBC and journal
⒎ High-performance clusters, client-server, point-to-point, are guaranteed by design
⒏ Support Ajax
⒐ Support integration with Axis
⒑ It is easy to call the embedded JMS provider for testing
RabbitMQ.
It supports the open Advanced Message Queuing Protocol (AMQP, Advanced Message Queuing Protocol), which fundamentally avoids the closure of manufacturers, and various customers using any language can benefit from it. This protocol provides a fairly complex message transmission mode, so it basically does not require the cooperation of MassTransit or NServiceBus.
ZeroMQ.
The company that developed this product is part of the AMQP group and also has a product called OpenAMQ. However, they split dramatically from AMQP, complaining that the product had lost its way and became more and more complex. ZeroMQ has a unique non-middleware model, that is, unlike several other tested products, you don't need to install and run a message server, or middleware. All you need is a simple reference to the ZeroMQ library, which can be installed using NuGet, and you can happily send messages between applications. Interestingly enough, they also use this approach to create an Erlang-style executive role in any language that leverages ZeroMQ for powerful in-process communication.
Introduction :
0MQ (ZeroMQ) is a lightweight messaging kernel. It is available for C, C++, Python, .NET/Mono, Fortran and Java languages. It runs on AIX, FreeBSD, HP-UX, Linux and MacOS , OpenBSD, OpenVMS, QNX Neutrino, Solaris and Windows operating systems.
Expansion :
There is a big cow in the blog garden who made a detailed supplement to ZeroMQ . Interested students can go and see for themselves. The corresponding address is provided below : http://news.cnblogs.com/n/154000/
test .
ActiveMQ requires Java to be installed on the target machine, and RabbitMQ requires an Erlang environment. I had no trouble installing either product, but I wonder if it adds a layer of tasks to the maintenance of the system. If one of these is picked, I need to get system maintainers to understand and maintain runtime libraries they are not familiar with before.
ActiveMQ, RabbitMQ and MSMQ all need to start the service process, these can be monitored and configured, the other one has problems.
ZeroMQ, which has no middleware architecture, does not require any service process and runtime. In fact, your application endpoint plays the role of this service. This makes deployment very easy, but the worry is that you have nowhere to watch if something goes wrong. As far as I know, ZeroMQ only provides non-persistent queues. You can implement your own auditing and data recovery functions where needed. Honestly, I'm not even sure if it should be included in this test, it works so differently than the others.
Below are the test results. Shows the number of messages sent and received per second. The whole process generates a total of 1 million 1K messages. Test execution was performed on a Windows Vista.
In summary:
The reception rate of MSMQ is 61.55%↓
The reception rate of ActiveMQ is 100%↑
The reception rate of RabbitMQ is 100%↑
The reception rate of ZeroMQ is 36.55%↓
As you can see, ZeroMQ is not at the same level as the others. Its performance is surprisingly high. To be fair, ZeroMQ is a beast compared to the others, but despite this, the conclusion is clear: If you want an application to send messages as fast as possible, you choose ZeroMQ. It's more valuable when you don't care too much about missing some messages by accident .
Although the speed of ZeroMQ is amazing, but for the era when data is life, we would rather reduce some requirements than lose any precious data, so in a comprehensive comparison, I think RabbitMQ is more suitable.