Welcome reprint, Reprint please indicate source: http://www.cnblogs.com/lidabnu/p/5723280.html
Message middleware has been popular for a long time, under normal circumstances, do not need to develop and design the message middleware from scratch, so the basic knowledge is to understand what the message middleware to solve the problem, how to evaluate the measurement of message middleware, and master the basic related terminology.
Professional terminology
- Message: A data structure that needs to be passed across systems
- Producer: The system that generates the message
- Consumer: A System of consumer messages
- Broker: Message relay role, responsible for the storage and forwarding of messages, called provider in the JMS specification
Application Scenarios
In summary, the message middleware is used to decouple producers and consumers, and the understanding now is mainly to reduce the "level of understanding or requirement" of the consumers bythe producer, specifically:
- Producers don't know or care about consumers, don't know or care whether consumers are likely to reduce or increase-- I don't know who you are .
- Producers know who consumers are, but the way consumers do it is completely different: for example, the integration of heterogeneous systems-- I know who you are, but I'm not asking you for what you 're doing.
- The quality attributes required by the producer and the consumer are different or are supported by different qualities:-- I know who you are, but I don't have much to ask of you.
- Response time requirements are different: for example, the order submission operation, the producer needs to respond to the end user in a timely manner, and the order processing can have a relatively long delay.
- Differences in availability: for example, when integrated with an external system, the availability of the external system is relatively low, and the message middleware can be used to mask this difference.
The problem that the message middleware realizes to solve
From the above scenario, the message middleware needs to address the following issues, or to have the following features
- I don't know who you are: supports the publish-subscribe model, which supports dynamic scaling and narrowing of the message consumer's range
- I know who you are and how I'm going to make it. No requirement: independent of the communication platform of consumers and producers, providing multiple technology access support
- I know who you are, I have no need for you to be good or bad:
- have enough message stacking capacity: corresponds to the consumer hangs up
- A pledge to "spend at least one time" on the message: It's not finished after the consumer has taken a message.
In addition to the above requirements, there are some common quality attribute requirements:
- Performance
- Scalable performance
- Reliability: Mainly refers to the reliability of the message, in all cases should not lose the message
- High availability: No downtime
- Ease of Use/serviceability:
- API Ease of Use
- Easy deployment
- Operation and maintenance Management easy: Easy to integrate with the existing monitoring system; facilitates granular management of messages in message middleware
And some of the problems to be solved after the asynchronous (message middleware is essentially a synchronous mutation step):
- Message Order Guarantee: first-produced messages need to be consumed first, and some scenarios are required
Finally, the brain map of the last learning process:
Message Middleware MQ basic knowledge
