The message reliability RabbitMQ

1, the import scene

As we all know, Rabbit MQ is a language written in Erlang, AMQP-based messaging middleware protocol. So the message transmission reliability is crucial, at this point, we look at the entire workflow Rabbit MQ:
Here Insert Picture Description
from above a figure, you can easily know that the message is sent by the producer, flows through Broker (channel - > switches -> queue), then consumer spending is completed, which is a complete message flow process. It will appear in this process is not reliable message transmission problem, after all, things are no absolutes Well, but the magic goes Road ridge, Rabbit MQ already developed a corresponding strategy for these unreliable issues, here's a look What unreliable problems in the process of message transmission has it.

1.1, producers message loss problem

Producers such as when sending a message, because of network problems, such as network packet loss, network failure led to the disappearance of loss.

1.2, Rabbit MQ messaging server loss problems:
  • Rabbit MQ server restart?
  • One service node is down clustered mode?
1.3, the message is lost consumer issues:

Consumers get the message, not the message processing is completed, there have been down, but this time Rabbit MQ server thinks you have consumed this message, we then arises the problem of the consumer message is lost.

2, Rabbit MQ message reliability

2.1, to solve the problem of producers message is lost
2.1.1, transaction mechanism

Rabbit MQ messaging provides a transaction mechanism, opening Affairs (channel.txSelect ()) before sending the message, and then start sending the message, the message is sent if a failure or abnormal, Rabbit MQ transaction will rollback, if successfully transmitted, directly commit the transaction (channel.txCommit), although this can ensure that messages are not lost.

But there is a drawback transaction mechanism, can cause manufacturers to end obstruction because it is a synchronous operation, it failed to send a message, until after receipt of the response Rabbit MQ, producers can continue to send a message, this will cause producers to produce message throughput the amount and performance is reduced a lot.

2.1.2, transmission confirmation mechanism (confirm mode)

Confirm the mode, all incoming channel messages will be assigned a unique ID, once entered into the message queue matching, RabbitMQ unique ID will be sent a confirmation message to the producer and the flag, which the manufacturers know the message has been correctly the destination queue; rabbitMQ not processed if the message is not a confirmation message is sent to you, you can perform a retry operation. This also ensures that messages are not lost.

Confirm there are three ways:

  • Serial mode
  • Batch mode confirm
  • Confirm Asynchronous mode: providing a callback method, broker confirm a plurality of messages or calls back to the end of the producer method.
2.2 address the Rabbit MQ messaging server loss problems:
2.2.1, Rabbit MQ server restarts

Under normal circumstances, the message is stored in memory, once the server is restarted, the memory is not the message get lost. Then make the message is not lost, you have the message saved in one place, so that even if the server is restarted, the next'll find the corresponding message in the preservation of the place, so the message will not be lost. Save the message down process is called message persistence. Because the messages are stored in the queue among, if not the queue, then certainly there will be no news, so will have to queue also persistent, so as to ensure the message is saved persistence. Of course, the switch can be selected for persistence, this selected according to need.

Queue persistence:

    /**
     * 设置持久化队列
     *
     * @return 返回队列
     */
    @Bean
    public Queue durableQueue() {
        //第一个参数是名字,第二个参数是代表是否持久化
        return new Queue(IMMEDIATE_QUEUE, true);
    }

News specific endurance of

       //消息持久化
        Message message = MessageBuilder.withBody("消失持久化".getBytes()).build();
        message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
2.2.2, a service is down a node clustered mode

Clustered mode, the case of a node server downtime, then it means that all messages node is temporarily unavailable, then the face of such a situation, there can be considered a backup server, the backup server to synchronize a front All message servers, so that after a node goes down, the server on the standby node quickly attached, this solves the problem of traffic paralysis. Rabbit MQ server such cluster pattern called mirror cluster mode , mirror mode using at least three nodes, two nodes and a disk memory nodes. FIG configuration is as follows:
Here Insert Picture Description
strategies mirror cluster:

  • Synchronize all nodes
  • Up with N nodes
  • Only the node synchronization to meet the specified name
2.3, the message is lost to resolve consumer problems:

Consumer information loss problem is the consumer in getting the message, whether or not the message processing is complete, the message is automatically returned to the RabbitMQ server to confirm the results, and this has led to the RabbitMQ server does not receive the results of consumer real deal completed this is because consumers are used to confirm the configuration automatically, without waiting for message processing is completed, after as long as consumers get a confirmation message automatically returns the results to the RabbitMQ server: the message has been confirmed consumed.

Therefore, consumers only need to automatically configure confirm confirmation to manual configuration to solve the problem it so that every time you need to wait for message processing is complete, consumers manually to confirm the results back to the RabbitMQ server, if the consumer is down the middle, so do not give RabbitMQ server returns a confirmation message, RabbitMQ server will then forward the message to other consumers this entry matched, this would resolve the problem of disappearing lost.

Such as infringement, please inform, Li deleted!

I welcome you to focus on the public JAVAERS number, accompany you learn together, grow together, sharing poetry and distant JAVA road together. In which public numbers are JAVA friend of this world, the public will have number-technical articles every day, by dry surface, but also the advanced architecture of e-books, such as Spring combat, SpringBoot practical, high-performance MySQL, in-depth understanding of JVM, RabbitMQ combat , Redis design and implementation of a number of high-quality books and so on, you can receive public attention No. Oh.
Here Insert Picture Description

Published 10 original articles · won praise 74 · views 4373

Guess you like

Origin blog.csdn.net/qq_36526036/article/details/105083762