首先上改良后的代码（改良前的代码和基本的配置使用在：RabbitMQ的介绍/安装和SpringBoot集成简单使用（MacBook版））：
Application.yml：
spring:
application:
name: cloud-purchase-service
rabbitmq:
host: 127.0.0.1
port: 5672
username: guest
password: 123456
Controller：
@Autowired
private RabbitMqService rabbitMqService;
@GetMapping("/rabbitMq")
public void rabbitMq(){
String s = rabbitMqService.sendData();
System.out.println("发送出去的："+s);
}
Server：
@Service
public class RabbitMqService {
@Autowired
RabbitTemplate rabbitTemplate;
public String sendData() {
String channelNo = "jojo123";
String randomNumber = new String(UUID.randomUUID().toString());
rabbitTemplate.convertAndSend("jojo_channel",null,randomNumber);
return randomNumber;
}
}
消费端我配了监听器：
@Component
public class RabbitMqAccept {
HashSet hashSet = new HashSet();
@RabbitListener(
bindings = @QueueBinding(
value = @Queue(value = "jojo_test_queue"),
exchange = @Exchange(value = "jojo_channel",type = "fanout")
)
)
@RabbitHandler
public void handle(@Payload String msg, Channel channel, @Headers Map<String,Object> headers) throws IOException {
// 获取到AMQP信道中的消息的唯一编号TagId，方便返回应答模式告知消息已接到
Long tag = (Long)headers.get(AmqpHeaders.DELIVERY_TAG);
try {
// 应答模式确认接收到消息,后面那个参数如果是false，就是只确认签收当前消息，如果是true，则签收全部比当前TagId小的消息
channel.basicAck(tag,false);
System.out.println(msg);
hashSet.add(msg);
System.out.println(hashSet);
System.out.println("请求了"+hashSet.size());
} catch (Exception e) {
e.printStackTrace();
System.out.println(e);
channel.basicNack(tag,false,true);
}
}
}
（1）小坑一：重复消费与重复发送
首先明确，我这里说的重复发送，指的是MQ往消费端推的发送，如果是生产者的重复发送，这个涉及到的接口幂等性问题可以看：接口幂等性问题
好了实验开始，疯狂点击刷新请求那个Controller，或者注释掉消费端，先开启生产端往MQ中写入30条数据。
开启消费端从MQ中读取：
读出了162条，其中细看的话很多关键信息是一样的，自己对比一下UUID+RandomNumber就可以知道。产生原因：我们为了防止消息丢失，一般都是默认开启应答模式，在应答模式中，如果没有及时返回ACK响应，那么MQ中的该条消息将不会移除，而是一直往消费端塞，但是另外一方面你的业务代码又确实拿到了数据，正在处理，而我们习惯开启手动ack的话把Ack放在业务代码的后面，这就会出现重复消费问题。
所以我就用了Set，因为这里只是测试MQ这个著名的BUG，如果是实际生产，可以传对象和Map，里面新增一个属性UUID拼随机数就行，用HashMap的Key放UUID也能达到排重的目的。我这里就简单Set，再试一次只发送十条。
这样就看到被限制住了。
（2）小坑二：Channel closed; cannot ack/nack 和 Channel shutdown: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - unknown delivery tag 1, class-id=60, method-id=80)
这个问题网上答案很少，我找了一段时间所以赶紧记下来这个小坑。
原因：RabbitMQ默认情况下是自动ACK应答模式，也就是只要默认开启应答并且是自动应答，然后从队列中删除消息。从我的yml配置文件和代码中可以看到，我没有关闭RabbitMQ自带的应答模式又开启了自己的手动channel.BasicACK()；那么就会出现channel already cloused 问题了。
解决方案：
1.改yml配置文件，代码不用改，关闭自动ACK，开启手动ACK：
# 设置监听为手动应答模式
listener:
simple:
acknowledge-mode: manual
测试成功不报错：
2.把代码中的channel.basicAck(tag,false);和channel.basicNack(tag,false,true);注释掉，使用默认的自动ACK：
小坑三：OOM？！我关闭了自动ACK，开启了手动ACK，然后开始写代码，有100行业务代码，最后才channel.BasicAck()；平时没问题，忽然有一行跳Exception，就返回消息队列中，继续推, 实习生代码套了太多if，try catch finally，或者某种情况忘了手动ack。会发生什么？
我们关掉全部的ACK，然后发消息到MQ，看会怎样：
是堆积，即使消费端已经把东西放进了Set，消费了，还是堆积在队列中，得不到释放。所以这也是为什么MQ默认给我们自动ACK的原因～
自动应答好还是手动应答好。
普通业务逻辑，调用链不长的，执行时间较短的，使用自动ACK。
处理时间较长的，可以等待消费端处理完成之后手动去确认。