Comment confirmer avec un message dans Springboot + RabbitMQ

                                                     

Récemment, le département a appelé tout le monde à organiser davantage de séances de partage technologique, affirmant que c'est pour activer l'atmosphère technique de l'entreprise, mais j'ai vu à travers tout et je sais que ce T M est juste pour le brushingKPI. Cependant, cela dit, c'est effectivement une bonne chose. Au lieu de tenir ces réunions ennuyeuses, faire des échanges plus techniques est toujours très utile pour la croissance personnelle.

Alors j'ai pris l'initiative de m'inscrire pour participer au partage, toux toux toux~, ce n'est vraiment pas pour ça KPI, je veux juste apprendre avec tout le monde !

Recommandations d'apprentissage associées : Tutoriel vidéo Java

Ce que je partage cette fois, c'est springboot + rabbitmq Comment mettre en œuvre le mécanisme de confirmation des messages et quelques pièges dans le développement réel. En fait, le contenu global est relativement simple. Parfois, les choses sont si simples, plus elles sont susceptibles de se produire. se tromper.

Vous pouvez constater qu'après avoir utilisé RabbitMQ, nos liens commerciaux sont évidemment devenus plus longs. Bien que le découplage entre les systèmes ait été réalisé, les scénarios pouvant entraîner une perte de messages ont également augmenté. Par exemple :

• Producteur de messages - > Serveur RabbitMQ (échec de l'envoi du message)

• Le serveur Rabbitmq lui-même a échoué, provoquant une perte de message

• Consommateur de messages - > service Rabbitmq (échec de la consommation des messages)

Donc, si vous ne pouvez pas utiliser le middleware, essayez de ne pas pour l'utiliser, si vous l'utilisez juste pour le plaisir, cela ne fera qu'augmenter vos ennuis. Après avoir activé le mécanisme de confirmation des messages, bien que la livraison précise des messages soit garantie dans une large mesure, en raison des interactions de confirmation fréquentes, rabbitmq l'efficacité globale devient faible et le débit chute sérieusement. Il n'est vraiment pas recommandé d'utiliser les messages. pour les messages qui ne sont pas très importants. Mécanisme de confirmation.

---

Ensuite, nous mettrons d'abord en œuvre le mécanisme de confirmation de message springboot + rabbitmq, puis ferons une analyse détaillée des problèmes rencontrés.

1. Préparer l'environnement

1. Présenter le package de dépendances lapinmq

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

2. . Modifier la configuration Application.properties

doit activer la confirmation des messages de 发送端 et 消费端.

spring.rabbitmq.host=127.0.0.1spring.rabbitmq.port=5672spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

# 发送者开启 confirm 确认机制
spring.rabbitmq.publisher-confirms=true# 发送者开启 return 确认机制
spring.rabbitmq.publisher-returns=true####################################################
# 设置消费端手动 ack
spring.rabbitmq.listener.simple.acknowledge-mode=manual
# 是否支持重试
spring.rabbitmq.listener.simple.retry.enabled=true

3. Définir Exchange et la file d'attente

Définir le commutateur confirmTestExchange et la file d'attente confirm_test_queue, et lier la file d'attente au commutateur. La confirmation du message de

@Configurationpublic class QueueConfig {

    @Bean(name = "confirmTestQueue")
    public Queue confirmTestQueue() {
        return new Queue("confirm_test_queue", true, false, false);
    }

    @Bean(name = "confirmTestExchange")
    public FanoutExchange confirmTestExchange() {
        return new FanoutExchange("confirmTestExchange");
    }

    @Bean    public Binding confirmTestFanoutExchangeAndQueue(
            @Qualifier("confirmTestExchange") FanoutExchange confirmTestExchange,
            @Qualifier("confirmTestQueue") Queue confirmTestQueue) {
        return BindingBuilder.bind(confirmTestQueue).to(confirmTestExchange);
    }}

rabbitmq est divisée en deux parties : la confirmation d'envoi du message et la confirmation de la réception du message.

2. Confirmation d'envoi du message

Confirmation d'envoi du message : permet de confirmer que le producteur producer envoie le message Si le message est remis avec succès à broker, allumez broker exchange puis envoyez-le à la file d'attente queue.

Les messages de producer à rabbitmq broker ont un modèle de confirmation confirmCallback.

L'échec de la livraison des messages de exchange à queue dispose d'un mode de secours returnCallback.

Nous pouvons utiliser ces deux Callback pour assurer une livraison à 100% du produit.

1. Mode de confirmation ConfirmCallback

Le rappel rabbitmq broker sera déclenché tant que le message sera reçu par confirmCallback.

@Slf4j
@Componentpublic class ConfirmCallbackService implements RabbitTemplate.ConfirmCallback {

    @Override    public void confirm(CorrelationData correlationData, boolean ack, String cause) {

        if (!ack) {
            log.error("消息发送异常!");
        } else {
            log.info("发送者爸爸已经收到确认，correlationData={} ,ack={}, cause={}", correlationData.getId(), ack, cause);
        }
    }}

implémente l'interface ConfirmCallback et réécrit sa méthode confirm() Il y a trois paramètres correlationData, ack et cause dans la méthode.

• correlationData : Il n'y a qu'un seul attribut id à l'intérieur de l'objet, qui est utilisé pour indiquer le caractère unique du message actuel.
• ack : Le message est remis au statut de broker, true indique le succès.
• cause : Indique la raison de l'échec de la livraison.

Mais le message reçu par broker ne peut signifier qu'il est arrivé sur le serveur MQ, et il n'y a aucune garantie que le message sera remis à la cible queue. Vous devez donc utiliser returnCallback ensuite.

2、 ReturnCallback 退回模式

如果消息未能投递到目标 queue 里将触发回调 returnCallback ，一旦向 queue 投递消息未成功，这里一般会记录下当前消息的详细投递数据，方便后续做重发或者补偿等操作。

@Slf4j
@Componentpublic class ReturnCallbackService implements RabbitTemplate.ReturnCallback {

    @Override    public void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {
        log.info("returnedMessage ===> replyCode={} ,replyText={} ,exchange={} ,routingKey={}", replyCode, replyText, exchange, routingKey);
    }}

实现接口ReturnCallback，重写 returnedMessage() 方法，方法有五个参数message（消息体）、replyCode（响应code）、replyText（响应内容）、exchange（交换机）、routingKey（队列）。

下边是具体的消息发送，在rabbitTemplate中设置 Confirm 和 Return 回调，我们通过setDeliveryMode()对消息做持久化处理，为了后续测试创建一个 CorrelationData对象，添加一个id 为10000000000。

@Autowired    private RabbitTemplate rabbitTemplate;

    @Autowired    private ConfirmCallbackService confirmCallbackService;

    @Autowired    private ReturnCallbackService returnCallbackService;

    public void sendMessage(String exchange, String routingKey, Object msg) {

        /**
         * 确保消息发送失败后可以重新返回到队列中
         * 注意：yml需要配置 publisher-returns: true
         */
        rabbitTemplate.setMandatory(true);

        /**
         * 消费者确认收到消息后，手动ack回执回调处理
         */
        rabbitTemplate.setConfirmCallback(confirmCallbackService);

        /**
         * 消息投递到队列失败回调处理
         */
        rabbitTemplate.setReturnCallback(returnCallbackService);

        /**
         * 发送消息
         */
        rabbitTemplate.convertAndSend(exchange, routingKey, msg,
                message -> {
                    message.getMessageProperties().setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                    return message;
                },
                new CorrelationData(UUID.randomUUID().toString()));
    }

三、消息接收确认

消息接收确认要比消息发送确认简单一点，因为只有一个消息回执（ack）的过程。使用@RabbitHandler注解标注的方法要增加 channel(信道)、message 两个参数。

@Slf4j
@Component
@RabbitListener(queues = "confirm_test_queue")public class ReceiverMessage1 {

    @RabbitHandler    public void processHandler(String msg, Channel channel, Message message) throws IOException {

        try {
            log.info("小富收到消息：{}", msg);

            //TODO 具体业务

            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);

        }  catch (Exception e) {

            if (message.getMessageProperties().getRedelivered()) {

                log.error("消息已重复处理失败,拒绝再次接收...");

                channel.basicReject(message.getMessageProperties().getDeliveryTag(), false); // 拒绝消息
            } else {

                log.error("消息即将再次返回队列处理...");

                channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true); 
            }
        }
    }}

消费消息有三种回执方法，我们来分析一下每种方法的含义。

1、basicAck

basicAck：表示成功确认，使用此回执方法后，消息会被rabbitmq broker 删除。

void basicAck(long deliveryTag, boolean multiple)

deliveryTag：表示消息投递序号，每次消费消息或者消息重新投递后，deliveryTag都会增加。手动消息确认模式下，我们可以对指定deliveryTag的消息进行ack、nack、reject等操作。

multiple：是否批量确认，值为 true 则会一次性 ack所有小于当前消息 deliveryTag 的消息。

举个栗子： 假设我先发送三条消息deliveryTag分别是5、6、7，可它们都没有被确认，当我发第四条消息此时deliveryTag为8，multiple设置为 true，会将5、6、7、8的消息全部进行确认。

2、basicNack

basicNack ：表示失败确认，一般在消费消息业务异常时用到此方法，可以将消息重新投递入队列。

void basicNack(long deliveryTag, boolean multiple, boolean requeue)

deliveryTag：表示消息投递序号。

multiple：是否批量确认。

requeue：值为 true 消息将重新入队列。

3、basicReject

basicReject：拒绝消息，与basicNack区别在于不能进行批量操作，其他用法很相似。

void basicReject(long deliveryTag, boolean requeue)

deliveryTag：表示消息投递序号。

requeue：值为 true 消息将重新入队列。

四、测试

发送消息测试一下消息确认机制是否生效，从执行结果上看发送者发消息后成功回调，消费端成功的消费了消息。

用抓包工具Wireshark 观察一下rabbitmq amqp协议交互的变化，也多了 ack 的过程。

五、踩坑日志

1、不消息确认

这是一个非常没技术含量的坑，但却是非常容易犯错的地方。

开启消息确认机制，消费消息别忘了channel.basicAck，否则消息会一直存在，导致重复消费。

2、消息无限投递

在我最开始接触消息确认机制的时候，消费端代码就像下边这样写的，思路很简单：处理完业务逻辑后确认消息， int a = 1 / 0 发生异常后将消息重新投入队列。

@RabbitHandler    public void processHandler(String msg, Channel channel, Message message) throws IOException {

        try {
            log.info("消费者 2 号收到：{}", msg);

            int a = 1 / 0;

            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);

        } catch (Exception e) {

            channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
        }
    }

但是有个问题是，业务代码一旦出现 bug 99.9%的情况是不会自动修复，一条消息会被无限投递进队列，消费端无限执行，导致了死循环。

本地的CPU被瞬间打满了，大家可以想象一下当时在生产环境导致服务死机，我是有多慌。

而且rabbitmq management 只有一条未被确认的消息。

经过测试分析发现，当消息重新投递到消息队列时，这条消息不会回到队列尾部，仍是在队列头部。

消费者会立刻消费这条消息，业务处理再抛出异常，消息再重新入队，如此反复进行。导致消息队列处理出现阻塞，导致正常消息也无法运行。

而我们当时的解决方案是，先将消息进行应答，此时消息队列会删除该条消息，同时我们再次发送该消息到消息队列，异常消息就放在了消息队列尾部，这样既保证消息不会丢失，又保证了正常业务的进行。

channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);// 重新发送消息到队尾channel.basicPublish(message.getMessageProperties().getReceivedExchange(),
                    message.getMessageProperties().getReceivedRoutingKey(), MessageProperties.PERSISTENT_TEXT_PLAIN,
                    JSON.toJSONBytes(msg));

但这种方法并没有解决根本问题，错误消息还是会时不时报错，后面优化设置了消息重试次数，达到了重试上限以后，手动确认，队列删除此消息，并将消息持久化入MySQL并推送报警，进行人工处理和定时任务做补偿。

3、重复消费

如何保证 MQ 的消费是幂等性，这个需要根据具体业务而定，可以借助MySQL、或者redis 将消息持久化，通过再消息中的唯一性属性校验。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!