概述
在實際生產(chǎn)環(huán)境中，我們更推薦使用RabbitMQ后臺管理頁面創(chuàng)建交換機、隊列、聲明綁定關(guān)系、配置死信隊列、延遲隊列等
今天帶大家看看如何在RabbitMQ后臺管理頁面操作這些東西
登錄管理后臺
創(chuàng)建隊列
點擊Exchange頁簽
填寫你要創(chuàng)建的交換機參數(shù)，注意選擇正確的Virtual host
在參數(shù)下方可以點擊，給你的交換機聲明備份交換機（關(guān)于備份交換機請看前面文章）
創(chuàng)建完成后效果如下：
創(chuàng)建隊列
點擊Queues頁簽
上圖中涂紅的部分我們可以指定隊列參數(shù)
例如：
創(chuàng)建后效果：
交換機與隊列綁定
對交換機和隊列進行綁定可以在Exchanges中聲明，也可以在Queues中聲明
下面以Queues中聲明為例：
點擊列表中隊列的名字，就會進入隊列詳情頁面
在這個隊列詳情頁面，我們可以指定交換機與隊列的綁定關(guān)系：
因為我聲明的是扇形交換機類型，所以我就不寫路由key了
點擊【Bind】按鈕，即可綁定成功
綁定成功后效果：
重復上述步驟，我們建立如下3個交換機和3個隊列：
總結(jié)一下：
- kc-guideorder-exchange是我們的業(yè)務(wù)要用的交換機（fanout類型），與隊列kc-guideorder-queue綁定，并且隊列kc-guideorder-queue我們設(shè)置了消息過期時間600s，消息過期后會成為死信，將會進入我們在隊列聲明時指定的死信隊列：kc-deadletter-exchange
- kc-deadletter-exchange同樣設(shè)計為fanout類型，它與隊列kc-deadletter-queue綁定，所以上面的死信最終會被存儲到隊列kc-deadletter-queue上
- 同時kc-guideorder-exchange我們?yōu)樗付艘粋€備份交換機kc-guideorder-queue-ae，發(fā)送到交換機kc-guideorder-exchange失敗的信息會被轉(zhuǎn)發(fā)到這個備份交換機上，備份交換機為與kc-guideorder-queue-ae這個隊列綁定，所以消息最終會存儲在隊列kc-guideorder-queue-ae上
測試
1.延遲隊列測試
我們往kc-guideorder-exchange這個交換機發(fā)送一條消息
@RestController
public class SendDelayMessageController {
@Autowired
RabbitSender rabbitSender;
@GetMapping("/sendDelayMessageAck")
public String sendDirectMessage() {
rabbitSender.convertAndSend("kc-guideorder-exchange", null, "Hell，我是延遲消息");
return "ok";
}
}
在對應(yīng)的隊列中發(fā)現(xiàn)存在此消息
等待10分鐘.....
消費端監(jiān)聽器代碼：
@RabbitListener(queues = "kc-deadletter-queue")
public void onMessage(Message message, Channel channel) throws IOException {
System.out.println("接收到消息總體內(nèi)容：" + message);
System.out.println("實際消息內(nèi)容：" + new String(message.getBody()));
// TODO 業(yè)務(wù)邏輯
// 1.獲取message中的body，解析消息內(nèi)容
// 2.其他業(yè)務(wù)邏輯......
// 回執(zhí)情形1：消費成功
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
// 回執(zhí)情形2：消費成功消費處理失敗，重新放入隊列（一定要慎用，防止造成無限返回隊列->消費者->返回隊列.....造成消息積壓）
// channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);
// 回執(zhí)情形3：消費處理失敗，拒絕接收（可以指定是否重新放入隊列，如果消息不重新放入隊列，RabbitMQ服務(wù)端會將消息移除）
// channel.basicReject(message.getMessageProperties().getDeliveryTag(), false);
}
控制臺輸出
接收到消息總體內(nèi)容：(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])
實際消息內(nèi)容："Hell，我是延遲消息"
2.備份交換機測試
為了測試備份交換機是否生效，我們先把kc-guideorder-exchange與隊列kc-guideorder-queue進行解綁，這樣發(fā)送到kc-guideorder-exchange的消息是找不到對應(yīng)的隊列的，測試其是否能為我們將消息轉(zhuǎn)發(fā)到備份交換機上
我們再發(fā)送一條消息
然后查看備份交換機隊列：
發(fā)現(xiàn)此隊列已經(jīng)存在一條消息
實際生產(chǎn)環(huán)境，我們可以消費此隊列做通知、或者其他補償措施
