[SpringBoot] Integrate RabbitMQ to ensure reliable delivery of messages

Producer side

Directory Structure

import dependencies

Modify yml

Business logic

Test Results


Producer side

Directory Structure

import dependencies

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-amqp</artifactId>
        <version>2.5.0</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Modify yml

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
    publisher-confirm-type: correlated # 开启确认回调
    publisher-returns: true # 开启退回回调

        There are three confirmation message acceptance types in publisher-confirm-type: none, correlated, simple.

        publisher-confirm-type: none disables publish confirm mode . is the default value . After using this mode, the ConfirmCallback callback will not be triggered regardless of whether the message is sent to the Broker (RabbitMQ).

        publisher-confirm-type: correlated indicates that the ConfirmCallBack callback is triggered after the message reaches the Broker successfully.

        publisher-confirm-type: simple means that if the message successfully arrives at the Broker, the ConfirmCallBack callback will be triggered. After the message is successfully published, use the rabbitTemplate to call the waitForConfirms() or waitForConfirmsOrDie() method to wait for the Broker node to return the sending result, and determine the next step based on the returned result logic. If the waitForConfirmsOrDie() method returns false, the channel channel will be closed, and then messages cannot be sent to the Broker.

Business logic

@SpringBootTest
@RunWith(SpringRunner.class)
class RabbitmqProducerApplicationTests {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    void testProducer() {
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            //三个参数分别为:相关配置消息、交换机是否收到消息、未收到消息的原因
            @Override
            public void confirm(CorrelationData correlationData, boolean b, String s) {
                if(b) System.out.println("交换机成功接受到了消息");
                else System.out.println("消息失败原因" + s);
            }
        });
        // 设置交换机处理失败消息的模式
        // true:消息到达不了队列时 会将消息重新返回给生产者 false:消息到达不了队列直接丢弃(默认)
        rabbitTemplate.setMandatory(true);
        rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {
            //五个参数分别为:消息对象、失败状态码、失败信息、交换机名称、路由键
            @Override
            public void returnedMessage(Message message, int i, String s, String s1, String s2) {
                System.out.println("队列接受不到交换机的消息进行了失败回调");
            }
        });
        rabbitTemplate.convertAndSend(RabbitMQConfig.EXCHANGE_NAME,"test.heHe","HelloWorld");
    }
}

Test Results

        In order to test whether the confirmation callback method, that is, the confirmCallBack() method, I deliberately wrote the name of the switch above

rabbitTemplate.convertAndSend(RabbitMQConfig.EXCHANGE_NAME + "1","test.heHe","HelloWorld");

        In order to test whether the return callback method, that is, the returnCallBack() method, I deliberately wrote the wrong name of the routing key above

rabbitTemplate.convertAndSend(RabbitMQConfig.EXCHANGE_NAME,"t.heHe","HelloWorld");

Summarize

        After the above two tests, you can use ConfirmCallBack and ReturnCallBack to confirm the reliability of message delivery. ConfirmCallBack is to confirm whether the switch can successfully receive the message, and ReturnCallBack is to confirm whether the queue can successfully receive the message from the switch. This is to solve the scenario that the message sender wants to prevent any message loss or delivery failure. But it should be noted that two lines of configuration must be added to yml.

Guess you like

Origin blog.csdn.net/m0_65563175/article/details/130455018