Weigh when news release
In RabbitMQ in the design, deliberately so that producers and consumers "decoupling" that is between the consumer release of information and messages are decoupled.
In RabbitMQ, there are different delivery mechanisms (producer), but each of these mechanisms have some impact on performance. In general, low fast reliability, poor reliability, good performance, specifically how to use needs to be based on your application, so that there is no best way, only the most appropriate way. Only your items and technology, in order to find your balance.
RabbitMQ in the actual project, the producers and consumers are clients, they can be completed affirm switches, affirmed queue and binding relationship, but in our actual process, we affirm the switch in the producer code, Affirming queue and binding relationship in the consumer code.
Also stated is that, when the producers announced that the consumer does not have to require, for RabbitMQ, if the producer is simple you just need to producers client, affirmed switches, affirmed queue to determine the binding relationship, data can be transmitted from the producer to the RabbitMQ. Just for the convenience of presentation, we use the data queue of consumer spending in the examples to show the results convenience.
Insecurity
Used in the presentation of various exchanger is insecure way through basicPublish post your message and use the correct switch and routing information, your message will be received and sent to the appropriate queue. But if there is a network problem, or a message can not be routed, or RabbitMQ their own problems, then there is risk in this way. So no guarantee of message generally not recommended.
Failed to confirm
Set mandatory flag when sending a message, telling RabbitMQ, if the message is not routable, the message should be returned to the sender and inform fail. Arguably, mandatory open failure detection mode is turned on.
Note: You notice it only makes RabbitMQ to fail without notification succeed. If the message is properly routed to the queue, then the publisher will not be any notification. The problem can not be brought to ensure dissemination of information must be successful because of the failure notification message may be lost.
channel.addConfirmListener RabbitMQ is used to monitor information sent back.
Small dessert listener
And closing the channel when the connection is closed, there are two listeners may be used
Affairs
It is provided primarily to achieve a transaction channel (Channel), and there are three main methods:
1. channel.txSelect () statement starts a transaction mode;
2. channel.txComment () commits the transaction;
3. channel.txRollback () rolls back the transaction;
Before sending a message, you need to declare channel mode for the transaction, the transaction can be committed or rolled back.
After opening transaction between the client and RabbitMQ communication interaction process:
- The client sends to the server Tx.Select (open transaction mode)
- Server-side return Tx.Select-Ok (open transaction mode ok)
- ·forward news
- The client sends to the transaction submitted Tx.Commit
- Server-side return Tx.Commit-Ok
This completes the interaction process a transaction, if any part of a problem which will be thrown IoException removed, so that the user can block abnormal transaction rollback, or decided not to repeat the message.
Well, since there is already a transaction, why use the sender to confirm this pattern here, the reason is because the performance of transactions is very poor. According to information, the transaction will be reduced by 2 to 10 times the performance.
Send confirmation mode
Transaction-based performance issues, RabbitMQ team we come up with a better solution is to use the sender to confirm mode, this mode is lighter than the amount of the transaction, the performance impact is almost negligible.
Principle: Manufacturer to confirm the channel setting mode, once the channel entering confirm mode, all published messages on the channel sides will be assigned a unique ID (starting at 1), between the producer and the id RabbitMQ confirmation message.
Message can not be routed, when the switch found message can not be routed to any queue will be performed to confirm the operation, it acknowledged receipt of the message. If the sender is set mandatory mode, it will first call the addReturnListener listener.
After routable message until the message is delivered to all matching queue, Broker sends an acknowledgment to the producer (the unique ID contained in the message), which message has the right to know the manufacturers reach the destination queue, and if the message queue is persistent, then the acknowledgment message will be sent after the message is written to disk, Broker acknowledgment message back to the producer of the delivery-tag field contains the sequence number of the acknowledgment message.
The biggest advantage is that he can confirm mode is asynchronous, once posted a message producer application can confirm the return channel while continuing to send the next message waiting, when the news finally confirmed, the producer will be able to apply through a callback way to handle the confirmation message, if RabbitMQ because of their own internal error message is lost, it will send a nack message producer application can process the same message nack decision further processing in the callback method.
Confirm three kinds of ways:
A mode: channel.waitForConfirms () Normal transmission confirmation pattern; message reaches the switch, returns true.
Second way: channel.waitForConfirmsOrDie () Batch acknowledged mode; synchronous mode and all messages will be performed after the transmission of the code behind, as long as one message will not reach the switch throws IOException.
Three ways: channel.addConfirmListener () asynchronous transmission confirmation monitor mode;
Standby switch
It is specified when the first switch statement, intended to provide a pre-existing switch, if the master switch can not route the message, then the message will be routed to the new standby switch.
If you set both mandatory announced what will happen? If the main switch can not route messages, RabbitMQ does not notify the publisher, because, sends a message to the standby switch to indicate the message has been routed. Note that the new standby switch is an ordinary switch, there is no special place.
Spare switches, as usual, and the standby switch statement Queue, Queue bound to the standby switch. And then when the main switch statement, by exchanging the parameters,
alternate-exchange ,, the standby switch is provided to the main exchanger.
Recommend alternate type switch is set to faout, Queue routing keys when binding to "#"
Consumer news
Reliability and performance trade-offs
Way to get the message
Get pull
Belongs to a polling model, it transmits a get request, to obtain a message. RabbitMQ at this time if there are no messages get a reply indicating a blank. In general, relatively poor performance in this way, it is clear that each message is obtained, and should RabbitMQ network communication request. And speaking of RabbitMQ, RabbitMQ can not make any optimization, because it never knows when an application sends a request. Specific use, referring to the code module packets cn.enjoyedu.consumer_balance.GetMessage in native. We are concerned to achieve, to be in a loop, continue to get the message server.
Push Consume
It belongs to a push model. After registering a consumer, RabbitMQ will be available at the time of the message, the message will automatically be pushed to consumers. This model we have used many times, specific use, see the code in native module package cn.enjoyedu.exchange.direct.
Reply message
As mentioned above, each message received by the customer must be confirmed. After message confirmation, RabbitMQ will delete this message from the queue, RabbitMQ unacknowledged messages will not set a timeout period, it is the only basis for judging whether the message needs to be re-delivered to the consumer is the consumer of the message is already connected consumer disconnect. Reason for this design is to allow consumers to consume a message RabbitMQ time can long, long time.
Automatic confirmation
Consumers statement queue AUTOACK parameters can be specified, when autoAck = true, once the consumer has received the message, it is confirmed as automatic message. If consumers during the processing of the message, went wrong, there was no way to re-process this message, so we often need to deal with after the message is successful, then a confirmation message, which requires manual confirmation.
Manual confirmation
When autoAck = false, RabbitMQ will wait for consumers to explicitly back after the ack signal from memory (disk and, if the message is persistent then) the removal of the message. Otherwise, RabbitMQ will remove it immediately after the message queue is consumed.
With the message confirmation mechanism, so as long as autoAck = false, consumers have enough time to process the message (task), do not worry about the message handling process after the consumer process hang message loss problem, because RabbitMQ will always hold messages until consumers explicit call up basicAck.
When autoAck = false when, for RabbitMQ server, the message in the queue into two parts: one is a message waiting for delivery to the consumer; part has been delivered to the consumer, but the consumer has not received ack signal messages. If the server has not received consumer ack signal, and the consumption of this message consumers have been disconnected, the server will arrange for the message to re-enter the queue, waiting for the next delivery to the consumer (or the original also possible that consumer).
By running the program, started two consumers A, B, can receive the message, but there are not a consumer A message to confirm when this consumer A closed, consumers will receive the original B a message sent to the consumer. Therefore, we generally use the manual approach is confirmed, the message processing in the try / catch statement block, the success of the treatment, give a response confirmation RabbitMQ, if the exception processing, in the catch, a reject message.
QoS prefetch mode
Before acknowledgment message is received, the consumer may be required in advance a certain number of messages received, after a certain number of messages processed, batch confirmation. If the consumer application crashes before the confirmation message, then all unacknowledged messages will be re-sent to other consumers. So here there is a certain degree of reliability risks.
This mechanism can be achieved on the one hand the speed limit (the RabbitMQ message to the temporary memory) effect, one can guarantee the quality of the message confirmation (such as confirmation of the deal, but there are unusual circumstances).
note:
Consumption must be non-acknowledged mode automatic ACK mechanism (this is the prerequisite for using baseQos, otherwise it will not take effect Qos), and then set the value basicQos; In addition, can also be set (global) based on the granularity of the channel and consume.
We can confirm the bulk, it can also be a single confirmation.
basicQos method parameters explained in detail:
prefetchSize: maximum transmission size limit of the content, not limited to 0, but said prefetchSize parameters, RabbitMQ not achieved.
prefetchCount: Do not tell RabbitMQ to push a consumer more than N messages, that if there is no ack N messages, then the consumer will block off until a message ack
global: true \ false if the above settings to the channel, simply put, is above the limit is channel level or consumer level.
If both the channel and consumers, what will happen? AMQP specification does not explain if a different global value multiple calls basic.qos what will happen. RabbitMQ interprets this to mean that two prefetch limit should be enforced independently of each other; the consumer only if the confirmation message does not reach the limit will not receive a new message.
channel.basicQos(10, false); // Per consumer limit
channel.basicQos(15, true); // Per channel limit
channel.basicConsume("my-queue1", false, consumer1);
channel.basicConsume("my-queue2", false, consumer2);
That is, the entire channel add Maximum unacknowledged message 15, each of the consumers a maximum of 10 message.
Consumer affairs
Use the same method and producers
Consumer model assumptions used in the transaction, and the transaction has been rolled back after the message acknowledgment, what would result?
The results are divided into two cases:
1. autoAck = false when a manual response is transactional, meaning that even if you have to manually confirm the message has been received, but returned to RabbitMQ message confirming the transaction will wait for the result of making a final decision or re-confirmation message back in the queue, if after you manually confirm, and roll back the transaction, then the transaction is rolled back to the subject, this provision back into the message queue;
2. autoAck = true if automatic acknowledgment is true that the situation does not support transactions, which means that even after you receive the message in rolling back a transaction does not help, and the message queue has been removed.