概述
在实际生产环境中，我们更推荐使用RabbitMQ后台管理页面创建交换机、队列、声明绑定关系、配置死信队列、延迟队列等
今天带大家看看如何在RabbitMQ后台管理页面操作这些东西
登录管理后台
创建队列
点击Exchange页签
填写你要创建的交换机参数，注意选择正确的Virtual host
在参数下方可以点击，给你的交换机声明备份交换机（关于备份交换机请看前面文章）
创建完成后效果如下：
创建队列
点击Queues页签
上图中涂红的部分我们可以指定队列参数
例如：
创建后效果：
交换机与队列绑定
对交换机和队列进行绑定可以在Exchanges中声明，也可以在Queues中声明
下面以Queues中声明为例：
点击列表中队列的名字，就会进入队列详情页面
在这个队列详情页面，我们可以指定交换机与队列的绑定关系：
因为我声明的是扇形交换机类型，所以我就不写路由key了
点击【Bind】按钮，即可绑定成功
绑定成功后效果：
重复上述步骤，我们建立如下3个交换机和3个队列：
总结一下：
- kc-guideorder-exchange是我们的业务要用的交换机（fanout类型），与队列kc-guideorder-queue绑定，并且队列kc-guideorder-queue我们设置了消息过期时间600s，消息过期后会成为死信，将会进入我们在队列声明时指定的死信队列：kc-deadletter-exchange
- kc-deadletter-exchange同样设计为fanout类型，它与队列kc-deadletter-queue绑定，所以上面的死信最终会被存储到队列kc-deadletter-queue上
- 同时kc-guideorder-exchange我们为它指定了一个备份交换机kc-guideorder-queue-ae，发送到交换机kc-guideorder-exchange失败的信息会被转发到这个备份交换机上，备份交换机为与kc-guideorder-queue-ae这个队列绑定，所以消息最终会存储在队列kc-guideorder-queue-ae上
测试
1.延迟队列测试
我们往kc-guideorder-exchange这个交换机发送一条消息
@RestController
public class SendDelayMessageController {
@Autowired
RabbitSender rabbitSender;
@GetMapping("/sendDelayMessageAck")
public String sendDirectMessage() {
rabbitSender.convertAndSend("kc-guideorder-exchange", null, "Hell，我是延迟消息");
return "ok";
}
}
在对应的队列中发现存在此消息
等待10分钟.....
消费端监听器代码：
@RabbitListener(queues = "kc-deadletter-queue")
public void onMessage(Message message, Channel channel) throws IOException {
System.out.println("接收到消息总体内容：" + message);
System.out.println("实际消息内容：" + new String(message.getBody()));
// TODO 业务逻辑
// 1.获取message中的body，解析消息内容
// 2.其他业务逻辑......
// 回执情形1：消费成功
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
// 回执情形2：消费成功消费处理失败，重新放入队列（一定要慎用，防止造成无限返回队列->消费者->返回队列.....造成消息积压）
// channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
// 回执情形3：消费处理失败，拒绝接收（可以指定是否重新放入队列，如果消息不重新放入队列，RabbitMQ服务端会将消息移除）
// channel.basicReject(message.getMessageProperties().getDeliveryTag(), false);
}
控制台输出
接收到消息总体内容：(Body:'"Hell，我是延迟消息"' MessageProperties [headers={spring_listener_return_correlation=ed70bfd9-a258-4a3b-ba14-f95e2635223e, spring_returned_message_correlation=20201215122141164475429, x-first-death-exchange=kc-guideorder-exchange, x-death=[{reason=expired, count=1, exchange=kc-guideorder-exchange, time=Tue Dec 15 12:31:41 CST 2020, routing-keys=[], queue=kc-guideorder-queue}], x-first-death-reason=expired, x-first-death-queue=kc-guideorder-queue, __TypeId__=java.lang.String}, contentType=application/json, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, redelivered=false, receivedExchange=kc-deadletter-exchange, receivedRoutingKey=, deliveryTag=1, consumerTag=amq.ctag-1lY9szRg4nFzYEvxFG-AHQ, consumerQueue=kc-deadletter-queue])
实际消息内容："Hell，我是延迟消息"
2.备份交换机测试
为了测试备份交换机是否生效，我们先把kc-guideorder-exchange与队列kc-guideorder-queue进行解绑，这样发送到kc-guideorder-exchange的消息是找不到对应的队列的，测试其是否能为我们将消息转发到备份交换机上
我们再发送一条消息
然后查看备份交换机队列：
发现此队列已经存在一条消息
实际生产环境，我们可以消费此队列做通知、或者其他补偿措施