Reprinted from http://blog.csdn.net/tenfyguo/article/details/7453355
In the system architecture design, we sometimes use the message queue, but for the corresponding why we need to use Message Queuing, the introduction of Message Queuing to the architectural design has more advantages, we have enough knowledge?
Does it exist in order to be introduced with Message Queuing? So here we need to be very clear about our architectural goals, in general, Message Queuing can provide help in the following ways:
1, guarantee the transmission of the message;
If the recipient is unavailable when the message is sent, the message queue retains the message until it is successfully passed;
2, provide asynchronous communication protocol;
The sender of the message sends the message to the message queue and can return immediately without waiting for the recipient's response, and the message is saved in the queue until the recipient takes it out;
3, decoupling;
As long as the message format is unchanged, even if the receiver's interface, location, or configuration changes, it will not bring any changes to the sender;
Moreover, the message sender does not need to know who the message receiver is, making the system design clearer;
Conversely, for example, the remote procedure call (RPC) or the service between the connection through the socket, if the other interface changes or the other IP, the port has changed, then the other party needs to rewrite the code or rewrite the configuration;
4, provide routing;
The sender does not need to establish a connection with the receiver, the two sides through the message queue to ensure that the message can be routed from the sender to the receiver, even for the two services that are not connected to each other network, can also provide message routing.
Attention to detail:
1, supports concurrency mode and sequential mode
Sequential mode:
After the message is received, other messages in the queue cannot be received until the message recipient has actively deleted the message. This ensures that the application processes the next task after a task has been completed, providing a strong sequence of
concurrency mode:
After the message is received, the next message of the queue can still be received by another application, and the next message is not received until the message receiver is actively deleted.
If the message is received and persisted (the time is available) is not deleted, the original recipient processing of the message is considered to be unsuccessful and the message is re-visible.
Can be received again by another application (this attribute is fault-tolerant, and the "Receive sequential queue message" feature is also available).
2, Momentary lock mode:
A message is not received by multiple services at the same time, which is guaranteed by a brief lock on the message, and the recipient of the message can specify when the message is locked.
If the recipient finishes processing the message and needs to actively delete the message, if the recipient fails to process the message, another service can regain the message after the lock on the message expires.
[Reprint] Design and use of distributed Message Queuing