RabbitMQ（三）消费端ack机制

ACK机制

什么是消息确认ACK

如果在处理消息的过程中，消费者的服务器在处理消息的时候出现异常，那么可能这条正在处理的消息就没有完成消息消费，数据就会丢失。为了确保数据不会丢失，RabbitMQ支持消息确定-ACK。

ACK的消息确认机制

ACK机制是消费者从RabbitMQ收到消息并处理完成后，反馈给RabbitMQ，RabbitMQ收到反馈后才将此消息从队列中删除。
如果一个消费者在处理消息出现了网络不稳定、服务器异常等现象，那么就不会有ACK反馈，RabbitMQ会认为这个消息没有正常消费，会将消息重新放入队列中。
如果在集群的情况下，RabbitMQ会立即将这个消息推送给这个在线的其他消费者。这种机制保证了在消费者服务端故障的时候，不丢失任何消息和任务。
消息永远不会从RabbitMQ中删除，只有当消费者正确发送ACK反馈，RabbitMQ确认收到后，消息才会从RabbitMQ服务器的数据中删除。

ACK机制的开发注意事项

如果忘记了ACK，那么后果很严重。当Consumer退出时候，Message会一直重新分发。然后RabbitMQ会占用越来越多的内容，由于RabbitMQ会长时间运行，因此这个"内存泄漏"是致命的。

代码演示

spring:
  #rabbit 配置信息
  rabbitmq:
    #发布者确认
    publisher-confirms: true
    #启动消息失败返回，此接口是在交换器路由不到队列时触发回调
    publisher-returns: true
    template:
      #启用强制信息；默认false
      mandatory: true
    listener:
      simple:
        #设置消费端手动 ack   none不确认  auto自动确认  manual手动确认
        acknowledge-mode: manual
        #是否启动时自动启动容器
        auto-startup: true
        #指定一个请求能处理多少个消息，如果有事务的话，必须大于等于transaction数量.
        prefetch: 10
        #决定被拒绝的消息是否重新入队；默认是true（与参数acknowledge-mode有关系） 
        default-requeue-rejected: false
        retry:
          #监听重试是否可用
          enabled: true

消费者消费消息，打印输出后面手动抛出运行时异常，观察现象。

/**
 * @author KimWu
 * @Description ：
 */
@Slf4j
@Component
@RabbitListener(
        //绑定队列
        bindings = @QueueBinding(
                //需要指定queue的名字
                value = @Queue(
                        //配置队列名称
                        value = "${rabbitmq.tenant.menu.name}",
                        //是否是一个可删除的临时队列 --> 消息持久化
                        autoDelete = "false"
                ),
                //配置交换器
                exchange = @Exchange(
                        //指定交换器名称
                        value = "${rabbitmq.tenant.menu.exchange}",
                        //指定具体的交换器类型,有常量类指定
                        type = ExchangeTypes.DIRECT
                ),
                //路由键
                key = "${rabbitmq.tenant.menu.routingkey}"
        )
)
public class TenantMenuListen {

    @Resource
    private AuthSysMenuService authSysMenuService;


    /**
     * 接受消息的方法，采用消息队列监听机制
     */
    @RabbitHandler
    @GlobalTransactional(rollbackFor = Exception.class)
    public void pay(String msg, Message message, Channel channel) throws Exception {
        /**
         * 该方法目前主要是同步菜单
         */
        try {
 			if(1 = 1){
 				throw new RuntimeException();
 			}
            //消费者手动ack机制
            channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

观察现象，如下所示：

在RabbitMQ的浏览器界面，可以看到一条消息未被进行ACK的消息确认机制，这条消息被锁定Unacked，所以一直在控制台进行报错。

控制台效果如下所示**，一直进行消息的发送，因为消费方一直没有返回ACK确认，RabbitMQ认为消息未进行正常的消费，会将消息再次放入到队列中，再次让你消费，但是还是没有返回ACK确认，依次循环，形成了死循环。**

如何解决问题呢，如果消息发送的时候，程序出现异常，后果很严重的，会导致内存泄漏的，所以可以使用RabbitMQ的ack确认机制。开启重试，然后重试次数，默认为3次。这里设置为5次。

spring:
  #rabbit 配置信息
  rabbitmq:
    #发布者确认
    publisher-confirms: true
    #启动消息失败返回，此接口是在交换器路由不到队列时触发回调
    publisher-returns: true
    template:
      #启用强制信息；默认false
      mandatory: true
    listener:
      simple:
        #设置消费端手动 ack   none不确认  auto自动确认  manual手动确认
        acknowledge-mode: manual
        #是否启动时自动启动容器
        auto-startup: true
        #指定一个请求能处理多少个消息，如果有事务的话，必须大于等于transaction数量.
        prefetch: 10
        #决定被拒绝的消息是否重新入队；默认是true（与参数acknowledge-mode有关系） 
        default-requeue-rejected: false
        retry:
          #监听重试是否可用
          enabled: true
          # 重试次数
          max-attempts: 5

效果如下所示：

可以看到控制台尝试了5次以后就不再进行重试了。

RabbitMQ的界面可以看到，开始的效果和上面的一致，但是5次尝试以后，就变成了0条。RabbitMQ将这条消息丢弃了。

小结：
那么在进行ack的时候，一定要设置重试次数，不然容易造成内存泄漏问题