Rabbit-ack

前提：消费者有异常，没有捕获，也没抛出

配置1：

  rabbitmq:
    addresses: 10.131.232.65:1004
    username: admin
    password: 123456
    virtual-host: /
    publisher-confirms: true
    listener:
      simple:
        acknowledge-mode: auto  #自动处理
        prefetch: 1  # 一次处理的消息数量

• 结果：

  
  Image 1.jpg
  

  一直打印报错信息，会导致磁盘利用率上升

  
  Image 3.jpg

• 原因：
  RabbitMQ消息监听程序异常时，consumer会向rabbitmq server发送Basic.Reject，表示消息拒绝接受，由于Spring默认requeue-rejected配置为true，消息会重新入队，然后rabbitmq server重新投递。就相当于死循环了，所以控制台在疯狂刷错误日志造成磁盘利用率飙升的原因。
  此处的 ready =1（表示消息处于就绪状态没有消费） 和total=1 （表示队列总消息条数为1）

配置2：自动处理

    listener:
      simple:
        acknowledge-mode: auto  #自动处理
        prefetch: 1  # 一次处理的消息数量
        default-requeue-rejected: false  #重试次数超过上面的设置之后是否丢弃（false不丢弃时需要写相应代码将该消息加入死信队列 默认true表示消息会重新入对）

• 结果

  
  Image 5.jpg
  Image 6.jpg
  

  程序依然在报错，但是队列里面已经没有数据了，此时就相当于重新再发了一次，但是还是错误的，就丢弃了，不管了，不太建议使用，可以通过判断消息中存在的唯一id或者是通过数据库来处理。

配置3：重试机制

    listener:
      simple:
        acknowledge-mode: auto  #自动处理
        prefetch: 1  # 一次处理的消息数量
        retry:
          max-attempts: 3 #最大重试次数
          enabled: true  #是否开启消费者重试（为false时关闭消费者重试，这时消费端代码异常会一直重复收到消息）
        default-requeue-rejected: false  #重试次数超过上面的设置之后是否丢弃（false不丢弃时需要写相应代码将该消息加入死信队列 默认true表示消息会重新入对）

这个是表示，重试3次后不成功就丢弃

Image 7.jpg
可以看到 此时的DeliveryTag仍然是1 表示的不是队列重新发送，而是指应用程序里面自己处理了3次。

配置4：没有ack。但是配置重试

    listener:
      simple:
        prefetch: 1  # 一次处理的消息数量
        retry:
          max-attempts: 3 #最大重试次数
          enabled: true  #是否开启消费者重试（为false时关闭消费者重试，这时消费端代码异常会一直重复收到消息）

Image 8.jpg
Image 9.jpg

• 结果
  可以看到，没有ack的前提下，配置重试次数，也能生效