四、消息发送机制、确认机制 五、避免消息重复投递和重复消费

四、消息发送机制、确认机制

    唯一保证消息不丢失的是使用事务，但是性能太差，作为补偿，有了消息确认机制，并且开启消息确认机制的方法和事务模式不共存。

    1、发送方确认机制和事务机制

        (1)、发送方确认机制：确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。发送确认分为两步，一是确认是否到达交换器，二是确认是否到达队列。

        a、确认是否到达交换器

• spring-boot中配置如下：spring.rabbitmq.publisher-confirms = true。信道设置成confirm模式（异步confirm模式、单条同步confirm模式、批量同步confirm模式）。

• 通过实现RabbitTemplate.ConfirmCallBack接口的confirm()方法，消息发送到交换器Exchange后触发回调该方法。

        方法：void confirm(CorrelationData var1, boolean var2, String var3);

            var1：消息的唯一标识

            var2：确认结果

            var3：失败原因

        b、确认是否到达队列

• spring-boot中配置如下：spring.rabbitmq.publisher-returns = true

• 通过实现RabbitTemplate.ReturnCallback接口的returnedMessage()方法，如果消息从交换器发送到对应队列失败时触发回调该方法（比如根据发送消息时指定的routingKey找不到队列时会触发）。

        方法：void returnedMessage(Message var1, int var2, String var3, String var4, String var5);

            var1：消息主体

            var2：消息主体

            var3：描述

            var4：消息使用的交换机

            var5：消息使用的rottingKey

        (2)、事务机制

        第一步：channel.txSelect: 将当前的Channel设置为事务模式；

        第二步：channel.txCommit: 提交当前的事务；

        第三步：channel.txRollback: 事务回滚。但是事务机制很耗费性能，所以不提倡使用事务。

    2、接收方确认机制（ACK确认机制）

        为了保证数据不被丢失，RabbitMQ支持消息确认机制，即ack。为了保证数据能被正确处理而不仅仅是被Consumer接收到，我们就不能采用no-ack或者auto-ack，我们需要手动ack(manual-ack)。在数据处理完成后手动发送ack，这个时候Broker才将Message删除。

        消息接收确认配置

        (1)、spring-boot中配置方法：spring.rabbitmq.listener.simple.acknowledge-mode = manual

            AcknowledgeMode.NONE：不确认

            AcknowledgeMode.AUTO：自动确认

            AcknowledgeMode.MANUAL：手动确认

                手动确认情况下，接收消息时消费者需要实现ChannelAwareMessageListener中的onMessage()方法

        (2)、手动成功确认

            消费者成功处理后，调用channel.basicAck(message.getMessageProperties().getDeliveryTag(), false)方法对消息进行确认。

            方法：void basicAck(long deliveryTag, boolean multiple) throws IOException;

                deliveryTag：该消息的index

                multiple：是否批量，true：将一次性ack所有小于deliveryTag的消息

        (3)、手动失败确认

            a、消费者成功处理后，调用channel.basicNack方法对消息进行失败确认。

                方法：void basicNack(long deliveryTag, boolean multiple, boolean requeue) throws IOException;

                    deliveryTag：该消息的index

                    multiple：是否批量。true：将一次性拒绝所有小于deliveryTag的消息

                    requeue：被拒绝的是否重新入队列。true：是

            b、消费者成功处理后，调用channel.basicReject方法对消息进行失败确认。

                方法：void basicReject(long deliveryTag, boolean requeue) throws IOException;

                    deliveryTag：该消息的index。

                    requeue：被拒绝的是否重新入队列。

            注：channel.basicNack与channel.basicReject的区别在于basicNack可以批量拒绝多条消息，而basicReject一次只能拒绝一条消息。

        思考：手动确认模式，消息手动拒绝中如果requeue为true会重新放入队列，如果此时只有一个消费者监听该队列，则有发生死循环的风险，多消费端也会造成资源的极大浪费，这个在开发过程中一定要避免的。

            解决方式：

                第一种方法是根据异常类型来选择是否重新放入队列。

                第二种方法是先成功确认，然后通过channel.basicPublish()重新发布这个消息。重新发布的消息网上说会放到队列后面，进而不会影响已经进入队列的消息处理。

---

---

五、避免消息重复投递和重复消费

    1、消息重复投递

        在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；

    2、重复消费

        在消息消费时，要求消息体中必须要有一个bizId（对于同一业务全局唯一，如支付ID、订单ID等）作为去重的依据，避免同一条消息被重复消费。