ZEROMQ Research and application analysis

Transferred from: http://www.cnblogs.com/rainbowzc/p/3357594.html

1 ZEROMQ Overview

ZEROMQ is a multi-threaded network library based on Message Queuing that abstracts the underlying details of socket types, connection processing, frames, and even routing, providing sockets that span multiple transport protocols. ZEROMQ is a new layer in network communication, between the application layer and the transport layer (according to TCP/IP division), it is a scalable layer, can run in parallel, dispersed in the distributed system.

2 system Architecture

2.1 Overall architecture

ZEROMQ almost all I/O operations are asynchronous and the main thread is not blocked. ZEROMQ creates the corresponding number of I/O Thread based on the interface parameters passed in when the user invokes the Zmq_init function. Each I/O thread has a poller,poller that is bound to it using the classic reactor pattern implementation, Poller different network I/O models based on different operating system platforms (SELECT, poll, Epoll, Devpoll, Kequeue, etc.). The main thread communicates with the I/O thread through the mail box to deliver the message. When the server starts listening or the client initiates the connection, it creates a zmq_connecter or Zmq_listener in the main thread, binds it to the I/O thread in the form of a message from the mail box, and the I/O thread puts the zmq_connecter or zmq_ Listener is added to Poller to listen for read/write events. When the server communicates with the client for the first time, Zmq_init is created to send the identity for authentication. After the certification, the two sides will create a session for this connection, and then communicate through the session. Each session is associated with the corresponding read/write pipeline, and the main thread is sending and receiving messages just reading/writing data from the pipeline separately. The session does not actually exchange I/O data with kernel, but instead exchanges I/O data with kernel by plugin to the engine in the session.

Figure 1 Overall architecture

2.2 Levels

ZEROMQ is not a separate service or program, just a set of components that encapsulate network communication, Message Queuing, thread scheduling and other functions, providing a concise API to the upper layer, the application by loading library files, calling API functions to achieve high-performance network communication.

Figure 2 The Hierarchy

2.3 Message Model

ZEROMQ divides the message traffic into 4 models, namely a pair of paired models (Exclusive-pair), a request response model (request-reply), a release subscription model (Publish-subscribe), a push-pull model (push-pull). These 4 models summarize the general network communication model, and in practice can combine 2 or more models to form their own solution according to the application needs.

2.3.1 Pair of paired models

The simplest 1:1 message communication model can be thought of as a TCP Connection, but TCP server can only accept one connection. The data can flow in two directions, which differs from the subsequent request response model.

2.3.2 Request Response Model

The request is initiated by the requester and then waits for the response side to answer. A request must correspond to a response, from the point of view of the request side is the hair-to-receive pairing, from the point of view of the response is the receive-send pair. The difference between a one-to-a-pair model is that the requester can be 1~n. The model is mainly used for remote invocation and assignment of tasks. Echo Service is the application of this classic model.

Figure 3 Request Response Model

2.3.3 Publish subscription model

The publishing side distributes data in one direction and does not care whether to send all the information to the Subscriber. If the Subscriber is not connected when the Publisher starts publishing information, the information is discarded directly. The problem that the Subscriber is not connected causes information to be lost, and can be resolved by combining with the request response model. The Subscriber is only responsible for receiving, not feedback, and at the subscriber consumption slower than the publisher, the Subscriber will accumulate data. This model is mainly used for data distribution. Weather forecasts, Weibo fans can apply this classic model.

Figure 4 Publishing a subscription model

2.3.4 Push-Pull model

Server side as the push side, and the client side as the pull end, if there are multiple clients connected to the server side at the same time, the server side will do a load balancing internally, using the average allocation algorithm, all message equalization to the client side. Compared with the publish-subscribe model, the push-pull model is not consumed without consumers, and can provide a multi-consumer parallel consumption solution in the case of insufficient consumer capability. This model is mainly used for multi-task parallelism.

Figure 5 Push-pull model

2.4 Communication Protocols

Provide four kinds of communication protocols in-process, inter-process, inter-machine, broadcast, etc. Communication protocol configuration is simple, with a URL-like string specified, the format is inproc://, ipc://, tcp://, pgm://. ZEROMQ automatically resolves the protocol, address, port number, and other information based on the specified string.

3 Work Flow

Figure 6 Basic Flow

4 Performance analysis

At present, there are many similar products on the market, there are 4 main kinds: MSMQ (Microsoft products), ActiveMQ (Java), RabbitMQ (Erlang), ZeroMQ (c + +). In addition to ZEROMQ, the other 3 products are a separate service or process, need to be installed and run separately, and have a certain dependence on the environment. Where MSMQ is very complex to install on a non-Windows platform, ACTIVEMQ requires an Erlang environment where JAVA,RABBITMQ is already installed on the target machine. The ZEROMQ is in the form of a library, which is loaded and run by the application. However, ZEROMQ only provides non-persistent Message Queuing.

Figure 7 is the performance test data from the Internet. Displays the number of messages sent and received per second. A total of 1 million 1K messages were generated throughout the process, and the test environment was Windows Vista. As you can see from the test data, ZEROMQ performance is much higher than the other 3 MQ.

But the test data is for reference only, because of the lack of necessary environmental parameters and performance indicators, such as: CPU parameters, memory parameters, message model, communication protocol, the limit of CPU consumption percentage, the limit of memory consumption percentage, and so on.

Figure 7 Performance Test

5 Application Scenarios

The Push-pull model of ZEROMQ is used to achieve "hot swap", load balancing and message dispatch of the joint-audience game server. According to the 8 deployment server, the push side acts as gateway, acting as a proxy for the top layer of a cluster of game servers, with load balancing, all Gameserver as pull ends. When a request arrives at the push End (Gateway), the push side distributes the task to the pull side (Gameserver) based on a certain allocation strategy. In a joint game A for example, when the game a just on-line, the expected maximum number of simultaneous online is 10W, a single gameserver concurrent processing capacity of 1W, need 10 units gameserver, because the game a playable very good, half a month after the maximum number of online people burst to 50W, Then do not need to be in the early morning of the gateway and Gameserver shut down, just need to add 40 new gameserver at any time in the engine room, start and connect to the gateway.

There is no requirement for the boot order of the client and server in Zeromq, and if communication between gameserver is required, Gameserver's application layer does not need to manage these details, ZEROMQ has already been re-connected.

Figure 8 Application Scenario

6 Summary

6.1 Simple

1, just provide 24 API interface, style similar to BSD Socket.

2, the network exception is handled, including the connection abnormal interrupt, the reconnection and so on.

3, change the TCP based on the byte stream to send and receive data, processing the sticky packet, half-pack and other problems, with MSG units to send and receive data, combined with protocol buffers, the application layer can be completely shielded network communication layer.

4, the big data through the Sendmore/recvmore to provide sub-packet transceiver mechanism.

5, through the data flow between threads to ensure that at the same time any data will only be held by a thread, in order to achieve multi-threaded "de-lock."

6, through the high water level HWM to control the flow, swap swap to dump memory data, to compensate for HWM lost data defects.

7, server-side and client start-up no sequencing.

6.2 Flexible

1, support a variety of communication protocols, can flexibly adapt to a variety of communications environment, including in-process, inter-process, inter-machine, broadcast.

2, support a variety of message models, message models can be combined with each other to form a specific solution.

6.3 Cross-platform

Linux, Windows, OS x, etc. are supported.

6.4 + languages

More than 30 development languages such as C, C + +, Java,. NET, Python can be bound.

6.5 High Performance

Compared with similar products, excellent performance.

ZEROMQ Research and application analysis