Message Middleware Selection

Message middleware is very important to the current large and medium-sized internet, which is second only to RPC service call in business data flow, which is responsible for the more and more complicated website business decoupling from the main process.
From the current needs of the Internet to the message middleware should be divided into two types, one is related to the demand for money, and money is not the demand; the reliability of money-related demand messages is put in the first place, and money-independent demand is the speed of the first place, but these two kinds of demand is contradictory, It is difficult to design a system that is both reliable and efficient, unless the two sets of scenarios are kneaded into a single system, which can be configured to select different schemes, but they are implemented in two ways. So there are several different design ways to meet the different needs of the industry.

Here are some typical implementation scenarios:

1. Reliability-First design principle based on ACTIVEMQ: simple, lightweight, easy to deploy (JMS provider responsible for message routing)

This kind of scheme stores all the message data and the sending State of the message on the message server, can guarantee the reliability of the message on the message service, but after adding many complex reliability guarantee means, the speed of the message from the Publisher to the Subscriber is bound to be affected. In this way, the publisher pushes the message to the message server, and the message server pushes the message to the Subscriber, which provides a good extensibility for the message sending policy;

ACTIVEMQ See also: http://manzhizhen.iteye.com/category/318342

2, the design principle of speed first with Kafka as the Representative

in this way, the sending State of the message is saved on the client side, while the client obtains the message from the message server in pull mode, because it is sequential read, but also takes a lot of guaranteed speed strategy, such as zero-copy, so this kind of scheme is faster, but sacrificed a lot of reliability assurance, More suitable for the Web2.0 site, these sites on the reliability of the message is not very high, and because of the production of a large number of user state-related messages, need an efficient system to process these messages, in addition, this scheme is more suitable for the collection of log messages;

3, the traditional decoupling scheme

Technical selection analysis of Message Queuing middleware see: http://www.cnblogs.com/lsx1993/p/4657897.html

Message Middleware Selection