A WinForm take you to play RABBITMQ (ii)

Follow up on a content installation, introduction and preliminary discussion below we'll go on to learn the next RABBITMQ.

I. Exchange Properties

　　Type

In the previous chapter, we said that the types of exchange are divided into fanout,direct,topic. There is also a less commonly used headers.
Headers this type of exchange binding ignores routingkey,headers is a key-value pair, you can define Chengcheng dictionaries, and so on. When the sender defines some key-value pairs at the time of sending, the receiver can then bind to some key-value pairs, and the corresponding queue can receive the message. There are two ways of matching all and any. Both of these methods must be defined at the receiving end with the key value "X-mactch". All represents a defined number of key-value pairs, and any code satisfies only one. Some of the previous Exchange Routingkey need to be in string form, while headers Exchange does not, because the value of a key-value pair can be any type
For example, the sender defines 2 key values {k1,1},{k2,2}, and the receiving end binds the queue with the definition {"X-match", "any"}, and the message can be obtained as long as there is {k1,1} or {k2,2} in the key value attribute of the receiving end.
This type of extension is large and suitable for very complex business scenarios.

　　Durability

Persistence, which is an optional property of exchange, and if you set the durability to False, the exchange is also destroyed when the current session ends.
Create a new transient exchange
　　
Close the current connection and look at it again.
　　

　　

Our new transient has been destroyed just now.

　　Auto Delete

　　When there is no queue or other exchange binds to this exchange, the exchange is destroyed. This is simply not an example.

　　Internal (relatively simple also not show)

　　Indicates that exchange cannot be used by the client to push messages, only for binding between Exchange and exchange.

PS: Cannot declare 2 exchange with the same name but different type

　　

Two. Queue Property

　　Durability and Exchange are the same, non-persisted queues that are destroyed after the service restarts.

　　Auto Delete The queue is automatically destroyed when no consumer is connected to the queue.

　　Exclusive makes the queue a private queue, which is useful only if the current application is available and you need to restrict the queue to only one consumer.

The extended attribute corresponds to the source program RabbitMQ.Client.IModel.QueueDeclare (string, BOOL, BOOL, BOOL, System.Collections.Generic.IDictionary <string,object>) The final parameters

　　message TTL The unit of time that can exist when a message is pushed in the queue (corresponding to the extension parameter argument "X-message-ttl")

　　How long the auto expire can be retained before the queue is automatically deleted (corresponding to the extension parameter argument "X-expires")

　　Max Length The number of prepared messages that a queue can hold (corresponding to the extension parameter argument "X-max-length")

... More reference http://www.rabbitmq.com/extensions.html

PS: Once you have created queues and switches, you cannot modify their flags. For example, if you create a non-durable queue and then want to change it to durable, the only way to do this is to delete the queue and recreate it.

Three. Message property

　　Durability

　　The persistence of messages is set in code in a different way than exchange and queue, there are 2 ways

1.

Ibasicproperties properties = Channel.　　Createbasicproperties (); Properties.　　Setpersistent (TRUE);　　byte[] Payload = Encoding.ASCII.GetBytes (message); Channel. Basicpublish (Exchange.name, TxtMessageRoutingKey.Text.Trim (), properties, payload);

2.

Ibasicproperties properties = Channel.　　Createbasicproperties (); Properties.　　DeliveryMode = 2;　　byte[] Payload = Encoding.ASCII.GetBytes (message); Channel. Basicpublish (Exchange.name, TxtMessageRoutingKey.Text.Trim (), properties, payload);

　　ContentType : A mime that identifies the content of the message, such as JSON with Application/json

　　Replayto: The address of the queue that identifies the callback

　　Correlationid: Used for the Association of Request and response to ensure the identity of requests and responses to messages

2 States of message:

　　Ready

Messages in this state exist in the queue pending processing.

　　Unacknowledged

　　A message in this state indicates that the process has not been acknowledged.

Speaking of unacknowledged, there is a need to understand the concept of an ACK. When the consumer receives the message and the processing task completes, an ACK with the message identifier is sent to tell the server that the message was received and processed for completion. RABBITMQ will wait until the link to the consumer of a message has been lost, only to be sure that the message is not handled correctly, thus RABBITMQ to re-send the message.
Message acknowledgment is turned off by default. There is a noack parameter when initializing consumer, and if set to true, this consumer will return an ACK immediately after the message is received.

String Basicconsume (string queue, bool Noack, RabbitMQ.Client.IBasicConsumer consumer)

Generally speaking, the common scenario noack is usually set to true, but for items with higher risk requirements, such as payment. For each message we need to ensure his integrity and correctness. After you have obtained the message, confirm that the correct business logic is executed and then proactively return an ACK to the server. You can view the messages in the queue by rabbitmqctl the list_queues name message_rady message_unacknowleded command, or you can manage the interface through the background.

Let's hold a message first.

　　

Then we close the link or restart the service

　　
The data is still intact.

Ps:message consumption is divided into consume and baseget the following when the cluster is introduced.

Four. Binding-related

If you bind a durable queue and a durable switch, RABBITMQ will keep this binding automatically. Similarly, if a queue or switch is deleted (whether durable or not), the bindings that depend on it are automatically deleted.

While declaring a queue, the server defaults to having this queue bound to the default exchange, which has an empty name.

Five. Publish a subscription

We have actually used the publish subscription model in our previous chapter's demo.

The core idea of the RABBITMQ message model is that the publisher (producer) does not send any messages directly to the queue. In fact, the publisher (producer) doesn't even know if the message has been posted to the queue. The publisher (producer) simply sends the message to an exchange. Exchange is as simple as receiving messages from the publisher side and pushing messages into the queue. Exchange must know how to handle the messages it receives, whether it should be pushed to a specified queue or multiple queues, or simply ignore the message. These rules are defined through Exchange type.

　　

Publishing a subscription is really simple, for example, in the example above, assuming we didn't have any news at first, there is now a producer P1, who is a weather player. Then we have 2 consumers to subscribe to his message.
P1 publishes his weather messages through the broadcast type of Switch Fex, C1,C2 establishes a team as Q1,Q2 respectively. and subscribe to P1 's fex.

Basic can
　　
When we P1 using FEX to generate a message, C1,C2 can get a message from P1 through Q1,Q2.

We have released 3 messages
　　
View queue Status
Q1:
　　
Q2:

　　

Q1,Q2 all got the news of the broadcast, as for how C1,C2 to consume the news, there is no interference with each other.

PS: A simple sentence the message generated by the Publisher in the publish subscription is pushed through exchange for all bound his queue formation messages, and each queue gets the message corresponding to the binding

Six. Consumer clusters

Differentiated from the publish subscription, consumer cluster mainly solve the problem of horizontal server expansion, if a queue backlog too much, how to let different consumers to bear.

　　

By default, RABBITMQ sends messages to each consumer (consumer) in order. On average, each consumer receives the same number of messages. This way of sending messages is called-polling (Round-robin).

We open 3 programs, 1 production of 2 consumption.

The binding relationship is as follows

　　

2 consumers use the same program, where the process PID is recorded, and the actual project can be differentiated by different servers.

　　

Start message consumption and enable consumers to handle work status

　　

And then we keep going through the producers this release message

　　

And then we look at the consumption of 2 consumers.

1.

　　

2.
　　

3.
　　

4.
　　

5.
　　
　　

By default, RABBITMQ will issue messages one at a consumer, and each consumer will receive the same number of messages. The reason for this is that the 1-article polling is because the program controls the amount of a single queue consumption.

void Basicqos (UINT prefetchsize, ushort Prefetchcount, BOOL global)

This article first to this, I hope to be helpful, next Monday to publish the third article.

A WinForm take you to play RABBITMQ (ii)