RabbitMQ入門（八）RabbitMQ的消息確認ACK

前言

      本章講解RabbitMQ的消息確認ACK機制

方法

1.概念

在前面的章節中，我們通過了持久化的設置避免了因消費者端突然宕機造成的消息丟失！

那麼即使消費者端沒有宕機，消息處理的時候也很容易出現異常，那麼我們認爲這個消息的消費是失敗的。

RabbitMQ通過消息確認的ACK機制來確認消息是否成功的進行消費，若消費者端消息處理拋出了異常，那麼該消息將重新放入隊列當中重新進行發送，直至消息正確的接收。

RabbitMQ的ACK消息確認機制是默認開啓的。

2.問題重現

我們依舊拷貝之前direct的示例工程：

我們依然稍微改動一下我們的provider的測試代碼：

package cn.edu.ccut;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

@RunWith(SpringRunner.class)
@SpringBootTest(classes=App.class)
public class RabbitMQTest {
	
	@Autowired
	private Provider provider;
	
	@Test
	public void testSendMsg() throws Exception{
		provider.sendMsg("hello rabbitmq !");
	}
}

這裏呢我們僅僅發送一條消息！

我們再次修改consumer端的代碼，讓接收消息的時候拋出異常：

package cn.edu.ccut;

import org.springframework.amqp.core.ExchangeTypes;
import org.springframework.amqp.rabbit.annotation.Exchange;
import org.springframework.amqp.rabbit.annotation.Queue;
import org.springframework.amqp.rabbit.annotation.QueueBinding;
import org.springframework.amqp.rabbit.annotation.RabbitHandler;
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;

@Component
@RabbitListener(bindings=
		@QueueBinding(
				value=@Queue(name="${mq.config.queue.vip}",autoDelete="true"),
				exchange=@Exchange(name="${mq.config.exchange}",type=ExchangeTypes.DIRECT),
				key="${mq.config.queue.vip.routing.key}"
		)
)
public class VipConsumer {

	@RabbitHandler
	public void receiveMsg(String msg){
		System.out.println("Vip Message is "+msg);
		//拋出異常的代碼
		int a = 1/0;
	}
}

此刻我們正常演示程序，觀察控制檯輸出：

我們發現控制檯不斷的閃爍，並且拋出異常！

這是因爲MQ一旦發現消息確認失敗了，會將消息重新放入隊列中進行發送，如此循環！

2.問題解決

該ACK確認機制有效的防止了消息的異常接收，但是暴露出的問題我們不得不引起重視！

我們在消費者端的application.properties文件中加入如下重試機制，代表着重試五次接收失敗便不再接受了！

#ACK config
spring.rabbitmq.listener.simple.retry.enabled=true
spring.rabbitmq.listener.simple.retry.max-attempts=5

當然了，你在消費者端的消息處理代碼可以加入try-catch進行異常的捕獲，也是未嘗不可的！