RABBITMQ Learning: (a) first knowledge, concept and experience

Because there is a very good online rmq http://lostechies.com/derekgreer/tag/rabbitmq/, so I do not say more, say I now read the author of the book, after his experience. (So to understand what I write, I need to read the author's letter of the book.) You can skip this one first, because my post will analyze the author's article in turn, and so on analysis of the book, you can go back to see I wrote this article.

First, install the RMQ, and after activating the Web Management Service (need to pause the service, then restart, see the Post), you can access through http://localhost:15672 (username/password is: guest/guest, This is called guest but is really super admin privilege).

This page is actually very interesting, so far, I think very useful content is that he can see your statement queue,exchange,routingkey (this to click on an Exchange to see). What's the use of seeing it? The most important thing is that they are real! and exists on the RMQ server! does not exist in producer, nor does it exist in consumer. In other words, they will not die as your program dies! (Of course your program let them die, of course they will die, I mean the general situation.) Well, at the start, if your program declares a queue and an exchange that does not automatically die, then the first run, the 2 objects are created, then they will always exist, the second run, you do not have to declare. This is why, in rabbitmq.client, some parameters are strings, not object instances of the generic class library.

The author did not clearly explain a few basic concepts:

1. Consumer is fetching messages directly from the queue without having to go through exchange. This is to be borne in mind, and it can be verified by accepting only the name of the queue from all APIs that cancel the interest.

2. Producer to send a message, it cannot be sent directly inside the queue, must pass through exchange, and the message must be specified routingkey. This can also be verified from the API of sending messages.

3. Exchange and queue (can be one-to-many) are bound to each other by Routingkey this "bond"! Exchange, Routingkey, and queue are closely related. Remember this too! When you send a message, you specify Exchange and Routingkey, and you cannot specify a queue. This is very make sense! A bit like the MVC relationship (producer is model, passing the message (with Routingkey) to Exchange,exchange is the controller that dispatches the message to the specified queue (s)).

4. There are 4 types of exchange: Direct, Fanout, Topic, Headers. This look at the back of the 4 picture is basically can understand.

5. RMQ provides a default exchange, whose name is an empty string. He is of the direct type, bound to all the queue (and the routingkey between each queue and this nameless exchange is the name of the queue). That's what the author says: Whenever you declare a queue, you have a default exchange. I don't know if he's right, but there's a default exchange on it. This doesn't have to be explicitly declared (it exists).

Here, post the PEQC diagram:

Here are some Exchange4 types: Direct, Fanout, Topic, Headers.

http://blog.csdn.net/puncha/article/details/8449273

RABBITMQ Learning: (a) first knowledge, concept and experience