1. 什么是消息中間件

消息中間件是在分布式系統(tǒng)中傳遞消息的軟件服務(wù)。它允許不同的系統(tǒng)組件之間通過(guò)消息進(jìn)行通信，而無(wú)需直接連接到彼此。消息中間件通常用于解耦系統(tǒng)的各個(gè)部分，提高系統(tǒng)的可擴(kuò)展性、靈活性和可維護(hù)性。

2. 消息中間件解決了什么問(wèn)題

2.1 異步處理

在業(yè)務(wù)沒(méi)有上下文依賴(lài)的前提下，將串行的業(yè)務(wù)執(zhí)行流程優(yōu)化成并行的方式，從而減少服務(wù)響應(yīng)的時(shí)間。
例如：在用戶(hù)注冊(cè)成功后，需要給用戶(hù)發(fā)送短信和郵箱注冊(cè)成功的通知，在此場(chǎng)景中，發(fā)送郵箱和短信通知不是必須要給客戶(hù)端響應(yīng)成功后通知，因此兩者可以和注冊(cè)的業(yè)務(wù)邏輯優(yōu)化成并行。也就是在用戶(hù)注冊(cè)信息成功持久化到數(shù)據(jù)庫(kù)后，直接給客戶(hù)端響應(yīng)注冊(cè)成功，而郵箱和短信可以通過(guò)異步執(zhí)行的方式，減少服務(wù)整體響應(yīng)時(shí)間，減少用戶(hù)的等待時(shí)長(zhǎng)。

2.2 服務(wù)解耦

將耦合的接口，通過(guò)消息中間件解耦，減少一個(gè)接口定義發(fā)生變化，導(dǎo)致其他調(diào)用方都需要修改的情況。
例如：用戶(hù)購(gòu)買(mǎi)商品，調(diào)用下訂單服務(wù)，再調(diào)用發(fā)貨服務(wù)，如果發(fā)貨服務(wù)需要進(jìn)行升級(jí)，發(fā)貨服務(wù)接口參數(shù)改變了，那么所有使用了發(fā)貨接口的服務(wù)，全部需要配合修改參數(shù)；如果使用了消息中間件，將用戶(hù)下單的信息發(fā)布到消息中間件中，發(fā)貨接口只需要訂閱消息中間件的訂單消息，當(dāng)有新的訂單時(shí)，再發(fā)貨，無(wú)論發(fā)貨接口的參數(shù)定義如何變化，都不會(huì)影響上游的接口功能

2.3 流量削峰

將集中在某一段時(shí)間的流量，存儲(chǔ)在一個(gè)池子里（消息中間件的隊(duì)列中），然后根據(jù)服務(wù)器的消費(fèi)能力進(jìn)行處理，而不是在流量高峰期，將所有的流量全部處理完畢。
例如：秒殺活動(dòng)，瞬間流量會(huì)非常大，如果服務(wù)器直接去處理這么大流量的請(qǐng)求，很容易導(dǎo)致整個(gè)應(yīng)用崩潰；通過(guò)消息隊(duì)列，將流量先暫存到隊(duì)列中，然后有服務(wù)器慢慢的消化，通過(guò)拉長(zhǎng)時(shí)間，減小服務(wù)器的壓力

3. 什么是RabbitMQ

RabbitMQ是使用Erlang語(yǔ)言開(kāi)發(fā)的，基于A(yíng)MQP高級(jí)消息隊(duì)列的開(kāi)源消息中間件

Erlang語(yǔ)言主要用于開(kāi)發(fā)并發(fā)和分布式系統(tǒng)，在電信領(lǐng)域得到廣泛應(yīng)用

4. 常見(jiàn)消息隊(duì)列產(chǎn)品

5. AMQP和JMS的區(qū)別

1. AMQP是一種消息隊(duì)列鏈接協(xié)議，AMQP不從API層進(jìn)行限定，而是直接定義網(wǎng)絡(luò)交換數(shù)據(jù)格式， 不規(guī)定實(shí)現(xiàn)方式，因此是跨語(yǔ)言的，而且消息模式更加豐富

常見(jiàn)支持AMQP的消息中間件：RabbitMQ、ActiveMQ、RocketMQ也支持

2. JMS是一套java的api規(guī)范，用于在分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信，具體的實(shí)現(xiàn)由各大消息中間件廠(chǎng)商提供。有兩種消息模式（點(diǎn)對(duì)點(diǎn)和分布訂閱模式）

許多常見(jiàn)的消息中間件都實(shí)現(xiàn)了JMS

6. RabbitMQ都有哪些消息模式\如何做到消息分發(fā)

6.1簡(jiǎn)單模式

單一生產(chǎn)者將消息發(fā)送到隊(duì)列，單一消費(fèi)者從隊(duì)列中接收消息。
適用于基本的點(diǎn)對(duì)點(diǎn)通信。

6.2 工作隊(duì)列模式

也是點(diǎn)對(duì)點(diǎn)的模式：一個(gè)生產(chǎn)者，可以對(duì)應(yīng)多個(gè)消費(fèi)者，但是只有一個(gè)消費(fèi)者可以獲得消息

6.3 發(fā)布/訂閱模式

生產(chǎn)者將消息發(fā)布到交換機(jī)（Exchange），多個(gè)隊(duì)列通過(guò)綁定到該交換機(jī)來(lái)接收消息。
消息會(huì)被廣播給所有與交換機(jī)綁定的隊(duì)列。

相關(guān)場(chǎng)景:郵件群發(fā),群聊天,廣播(廣告)

6.4 路由模式

隊(duì)列和交換機(jī)綁定以及生產(chǎn)者向交換機(jī)發(fā)送消息時(shí)，都需要指定一個(gè)路由key，路由key相同，消息才會(huì)成功投遞到對(duì)應(yīng)路由key的隊(duì)列

6.5 Topic(主題)模式

Topic模式在路由模式的基礎(chǔ)上更進(jìn)一步，實(shí)現(xiàn)通配符進(jìn)行模糊匹配的機(jī)制

6.6 RPC模式

1. 服務(wù)端創(chuàng)建RPC隊(duì)列，等待客戶(hù)端的請(qǐng)求
2. 客戶(hù)端發(fā)送請(qǐng)求時(shí)，需要攜帶一個(gè)接受服務(wù)端響應(yīng)結(jié)果的隊(duì)列，以及一個(gè)correlation_id

因?yàn)樗许憫?yīng)消息都通過(guò)一個(gè)隊(duì)列接收，所以通過(guò)綁定一個(gè)唯一標(biāo)識(shí)correlation_id來(lái)分辨響應(yīng)消息對(duì)應(yīng)的請(qǐng)求。

3. 服務(wù)端將響應(yīng)的消息，放到服務(wù)端傳過(guò)來(lái)的響應(yīng)隊(duì)列
4. 客戶(hù)端會(huì)一直監(jiān)聽(tīng)自己的響應(yīng)隊(duì)列，等待服務(wù)端的響應(yīng)
5. 客戶(hù)端收到自己響應(yīng)隊(duì)列的服務(wù)端響應(yīng)結(jié)果后，判斷標(biāo)識(shí)correlation_id是否和自己發(fā)出請(qǐng)求時(shí)攜帶的標(biāo)識(shí)一致，一致代表結(jié)果是自己請(qǐng)求的結(jié)果，不是丟掉

RPC服務(wù)器可能會(huì)在向我們發(fā)送答案后，在發(fā)送請(qǐng)求確認(rèn)消息之前死亡，重啟的RPC服務(wù)會(huì)重新處理客戶(hù)端的這個(gè)請(qǐng)求，直接丟棄可以防止重復(fù)響應(yīng)

7. 交換機(jī)有哪些類(lèi)型

1. Fanout：廣播，將消息交給所有綁定到交換機(jī)的隊(duì)列
2. Direct：定向，把消息交給符合指定routing key 的隊(duì)列
3. Topic：通配符，把消息交給符合routing pattern（路由模式） 的隊(duì)列
4. 4、headers(不推薦)
   headers 類(lèi)型的交換器不依賴(lài)于路由鍵的匹配規(guī)則來(lái)路由消息，而是根據(jù)發(fā)送的消息內(nèi)容中的 headers 屬性進(jìn)行匹配

8. RabbitMQ的結(jié)構(gòu)是什么樣的

1. Producter：生產(chǎn)者，是消息的發(fā)送放，將消息發(fā)送給Exchange交換器
2. Consumer：消費(fèi)者，是消息的接收方，從消息隊(duì)列中獲取消息，并處理消費(fèi)
3. Broker：接收和分發(fā)消息的應(yīng)用，RabbitMQ Server就是Message Broker
4. Virtual Host：當(dāng)多個(gè)不同的用戶(hù)使用同一個(gè)RabbitMQ Server時(shí)，可以劃分出多個(gè)Virtual Host，每個(gè)用戶(hù)在自己的Virtual Host中創(chuàng)建Exchange/Queue等
5. Exchange：交換器，根據(jù)分發(fā)規(guī)則，匹配RoutingKey路由鍵，將消息分發(fā)到Queue隊(duì)列中
6. Queue：消息隊(duì)列，存儲(chǔ)消息的容器，消息最終會(huì)被送到這里，等待consumer取走
7. Binding：Exchange和Queue之間的虛擬連接，binding 中可以包含 routing key，Binding 信息被保存到 exchange 中的查詢(xún)表中，用于 message 的分發(fā)依據(jù)
8. Connection：publisher／consumer 和 broker 之間的 TCP 連接
9. Channel 是在 connection 內(nèi)部建立的邏輯連接，如果每一次訪(fǎng)問(wèn) RabbitMQ 都建立一個(gè) Connection，建立 TCP Connection的開(kāi)銷(xiāo)將是巨大的，效率也較低。

9. RabbitMQ如何實(shí)現(xiàn)消費(fèi)端限流

消費(fèi)端限流是保護(hù)消費(fèi)者所在服務(wù)器的手段，當(dāng)流量達(dá)到高峰時(shí)，MQ的消費(fèi)者如果不加限制的進(jìn)行消費(fèi)，服務(wù)器肯定容易掛掉，甚至重啟之后依然無(wú)法解決。RabbitMQ可以通過(guò)basicQos方式，配置MQ服務(wù)器一次性傳遞給消費(fèi)者的最大消息數(shù)量，當(dāng)達(dá)到這個(gè)數(shù)量后，RabbitMQ不再推送新的消息給消費(fèi)者，實(shí)現(xiàn)消費(fèi)端限流。

1. 實(shí)現(xiàn)這個(gè)功能需要關(guān)閉自動(dòng)提交

channel.basicConsume(queueName, false, consumer);

2. 配置限流

// 服務(wù)器可以將1條消息預(yù)先發(fā)送給消費(fèi)者，而不需要等到消費(fèi)者確認(rèn)已經(jīng)處理完先前的消息。
channel.basicQos(1);

10. RabbitMQ消息存活時(shí)間（TTL）了解么

當(dāng)消息到達(dá)存活時(shí)間后，還沒(méi)有被消費(fèi)，會(huì)被自動(dòng)清除。RabbitMQ可以對(duì)消息設(shè)置過(guò)期時(shí)間，也可以對(duì)整個(gè)隊(duì)列（Queue）設(shè)置過(guò)期時(shí)間。

11. 死信隊(duì)列

11.1 什么是死信隊(duì)列

DLX，當(dāng)消息在隊(duì)列中變成dead message后，會(huì)被重新發(fā)送到另外一個(gè)交換器中，這個(gè)就換器綁定的隊(duì)列被稱(chēng)為死信隊(duì)列

11.2 導(dǎo)致消息死信的原因

1. 消息被消費(fèi)者拒收（不重會(huì)隊(duì)列）

// 拒絕簽收,不重回隊(duì)列 requeue=false
channel.basicNack(deliveryTag,true,false);

2. 隊(duì)列中的消息存在過(guò)期設(shè)置，消息到達(dá)超時(shí)時(shí)間未被消費(fèi)
3. 隊(duì)列消息達(dá)到上限，超出的消息就會(huì)進(jìn)入死信隊(duì)列

11.2 死信的處理方式

1. 如果消息不重要，可以選擇丟棄
2. 將死信的消息入庫(kù)，如果必要，可以講死信消息重新處理
3. 通過(guò)監(jiān)聽(tīng)死信隊(duì)列的程序進(jìn)行處理（常用）

11.3 延遲隊(duì)列

消費(fèi)者不馬上處理消息，而是延遲一段時(shí)間之后再處理
例如：在訂單系統(tǒng)中，如果用戶(hù)超過(guò)30分鐘未支付則取消訂單
RabbitMQ的方式有兩種：

1. TTL+死信隊(duì)列的方式實(shí)現(xiàn)延遲隊(duì)列的效果，實(shí)現(xiàn)過(guò)程麻煩一些
   

• 訂單交換機(jī)綁定訂單死信隊(duì)列和訂單過(guò)期隊(duì)列
• 訂單過(guò)期后，通過(guò)路由鍵將TTL過(guò)期的消息投遞到訂單的過(guò)期隊(duì)列
• 監(jiān)聽(tīng)訂單過(guò)期隊(duì)列的消費(fèi)者，從訂單過(guò)期隊(duì)列取出的消息都是超時(shí)未支付的訂單

2. RabbitMQ3.5.7以上版本提供了插件（rabbitmq-delayed-message-exchange），可以實(shí)現(xiàn)延遲隊(duì)列功能，實(shí)現(xiàn)簡(jiǎn)單，但是插件版本和MQ版本要對(duì)應(yīng)，不能過(guò)高或者過(guò)低，要重啟RabbitMQ才會(huì)生效

12. RabbitMQ如何保證消息可靠性

12.1 如何保證消息消息不丟失

RabbitMQ在生產(chǎn)者投遞消息是有兩個(gè)過(guò)程可能導(dǎo)致消息丟失，分別是消息發(fā)送到交換機(jī)，和消息從交換機(jī)到對(duì)列的過(guò)程；針對(duì)到交換機(jī)的過(guò)程使用Publisher Confirm，針對(duì)交換機(jī)到對(duì)列使用Publisher Returns。

12.1.1 服務(wù)端使用確認(rèn)機(jī)制-保證消息成功投遞

1. Publisher Confirm
   消息成功到達(dá)交換機(jī)，RabbitMQ會(huì)給生產(chǎn)者發(fā)送ACK確認(rèn)信號(hào)，如果發(fā)生交換機(jī)不存在，或者路由鍵不匹配導(dǎo)致消息無(wú)法被處理，RabbitMQ會(huì)給生產(chǎn)者發(fā)送NACK否認(rèn)信號(hào)
2. Publisher Returns
   如果消息成功路由到消息隊(duì)列，不會(huì)返回消息，否則會(huì)將無(wú)法路由的消息發(fā)送給生產(chǎn)者

RabbitMQ通過(guò)以上兩種確認(rèn)回調(diào)監(jiān)聽(tīng)的方式，用于消息無(wú)法正常投遞到交換機(jī)或消息隊(duì)列時(shí)通知給生產(chǎn)者，再投遞失敗后，我們可以通過(guò)重試的方式保證消息一定發(fā)送成功

3. 案例代碼

• 引入依賴(lài)

<dependency><groupId>com.rabbitmq</groupId><artifactId>amqp-client</artifactId>
</dependency>
<dependency><groupId>org.springframework.amqp</groupId><artifactId>spring-rabbit</artifactId>
</dependency>

• 代碼

import org.springframework.amqp.core.*;
import org.springframework.amqp.rabbit.core.RabbitTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Bean;import java.nio.charset.StandardCharsets;public class RabbitMQSendMsgExample {@Autowiredprivate RabbitTemplate rabbitTemplate;public void sendMsg() {/*** Publisher Confirm確認(rèn)模式回調(diào)* 確認(rèn)模式開(kāi)啟：ConnectionFactory中開(kāi)啟publisher-confirms="true"*/rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {if (ack) {//接收成功System.out.println("接收成功消息" + cause);} else {//接收失敗System.out.println("接收失敗消息" + cause);//做一些處理,讓消息再次發(fā)送。}});/*** Publisher Returns回退模式回調(diào)* 開(kāi)啟回退模式：publisher-returns="true"*/rabbitTemplate.setMandatory(true);rabbitTemplate.setReturnCallback(new RabbitTemplate.ReturnCallback() {/*** @param message   消息對(duì)象* @param replyCode 錯(cuò)誤碼* @param replyText 錯(cuò)誤信息* @param exchange  交換機(jī)* @param routingKey 路由鍵*/@Overridepublic void returnedMessage(Message message, int replyCode, String replyText, String exchange, String routingKey) {System.out.println("return 執(zhí)行了....");System.out.println(message);System.out.println(replyCode);System.out.println(replyText);System.out.println(exchange);System.out.println(routingKey);//處理}});Message message = MessageBuilder.withBody("消息".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.PERSISTENT).build();//3. 發(fā)送消息rabbitTemplate.convertAndSend("RabbitMQ_Message", "routingKey", message);}

12.1.2 使用持久化機(jī)制-保證服務(wù)宕機(jī)重啟后消息不丟

消息成功投遞到消息隊(duì)列，并不以為著業(yè)務(wù)完成，RabbitMQ在接收到消息暫存在內(nèi)存，如果此時(shí)RabbitMQ掛掉了，消息還是會(huì)丟失，所以通過(guò)持久化機(jī)制來(lái)保證業(yè)務(wù)成功執(zhí)行

1. 持久化消息隊(duì)列，交換機(jī)
   持久化后的交換機(jī)和消息隊(duì)列，在RabbitMQ重啟后會(huì)保留，保證隊(duì)列和交換機(jī)的數(shù)據(jù)不丟失

    @Beanpublic Queue TestQueue() {//第二個(gè)參數(shù)durable:是否持久化,默認(rèn)是falsereturn new Queue("queueName", true, true, false);}@Beanpublic DirectExchange mainExchange() {//第二個(gè)參數(shù)durable:是否持久化,默認(rèn)是falsereturn new DirectExchange("exchangeNamw", true, false);}

2. 持久化消息
   在發(fā)布消息時(shí)，可以通過(guò)設(shè)置消息的 deliveryMode 屬性為 2 來(lái)將其標(biāo)記為持久化，服務(wù)器重啟后可以確保消息不丟失，不過(guò)設(shè)置消息的持久化會(huì)增加磁盤(pán)的IO開(kāi)銷(xiāo)

Message message = MessageBuilder.withBody("消息".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.PERSISTENT).build();//3. 發(fā)送消息rabbitTemplate.convertAndSend("RabbitMQ_Message", "routingKey", message);

12.1.3 客戶(hù)端消息確認(rèn)-保證消息成功投遞給消費(fèi)者

有了持久化之后，如何保證消息被消費(fèi)者成功消費(fèi)
消費(fèi)者再成功處理消息之后，可以向RabbitMQ發(fā)送ACK回執(zhí)，RabbitMQ收到ACK回執(zhí)后刪除改消息，保證消息不丟失，如果出現(xiàn)異常，就會(huì)返回NACK回執(zhí)，MQ就會(huì)重新投遞一次消息，如果消費(fèi)者一直沒(méi)有返回任何回執(zhí)消息，MQ也會(huì)嘗試重新投遞一次消息。

ACK表示消費(fèi)和收到消息后確認(rèn)的方式，有兩種確認(rèn)方式，分別是自動(dòng)確認(rèn)（默認(rèn)）和手動(dòng)確認(rèn)

1. 自動(dòng)確認(rèn)：消息一旦被消費(fèi)者接收到，就會(huì)自動(dòng)確認(rèn)，并且將消息從消息隊(duì)列移除，但是在實(shí)際的業(yè)務(wù)當(dāng)中，可能消息接收到了，但是業(yè)務(wù)處理出現(xiàn)異常了，那改消息就相當(dāng)于丟失了
2. 手動(dòng)確認(rèn)：需要在業(yè)務(wù)成功處理后，調(diào)用channel.basicAck()，手動(dòng)簽收，如果出現(xiàn)異常，則在catch中調(diào)用 basicNack，拒絕消息，讓MQ重新發(fā)送消息。

12.1.4 結(jié)合本地消息表-保證消息成功被業(yè)務(wù)邏輯處理

雖然我們經(jīng)過(guò)一些列的持久化，確認(rèn)機(jī)制，但是依然存在消費(fèi)者確認(rèn)消息后沒(méi)來(lái)得及使用消息出現(xiàn)宕機(jī)的情況，這個(gè)消息依然被認(rèn)為丟失，此時(shí)需要在數(shù)據(jù)庫(kù)中除了基礎(chǔ)的業(yè)務(wù)表，針對(duì)消息隊(duì)列也需要建立一張表，用來(lái)監(jiān)控消息隊(duì)列中消息最終的狀態(tài)，將最終依然失敗的消息，通過(guò)定時(shí)任務(wù)隔一段時(shí)間將失敗的消息重新處理
針對(duì)消息隊(duì)列消息處理情況日志表

CREATE TABLE `broker_message_log` (`message_id` varchar(255) NOT NULL COMMENT '消息唯一ID',`message` varchar(4000) NOT NULL COMMENT '消息內(nèi)容',`try_count` int(4) DEFAULT '0' COMMENT '重試次數(shù)',`status` varchar(10) DEFAULT '' COMMENT '消息投遞狀態(tài) 0投遞中,1投遞成功,2投遞失敗',`error_message` varchar(4000) NOT NULL COMMENT '失敗原因',`next_retry` timestamp NOT NULL DEFAULT '0000-00-00 00：00：00' ON UPDATE CURRENT_TIMESTAMP COMMENT '下一次重試時(shí)間',`create_time` timestamp NOT NULL DEFAULT '0000-00-00 00：00：00' ON UPDATE CURRENT_TIMESTAMP,`update_time` timestamp NOT NULL DEFAULT '0000-00-00 00：00：00' ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (`message_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

1. 將消息信息存儲(chǔ)在數(shù)據(jù)庫(kù)中，初始狀態(tài)0投遞中
2. 在所有業(yè)務(wù)全部成功處理后，將狀態(tài)設(shè)置為1投遞成功，中間出現(xiàn)的任何異常都記錄2投遞失敗，同時(shí)記錄回調(diào)或者手動(dòng)ACK將失敗信息
3. 創(chuàng)建定時(shí)任務(wù)，根據(jù)業(yè)務(wù)需要拉取狀態(tài)為2失敗的消息，進(jìn)行最大努力重試，重試超過(guò)一定次數(shù)還是失敗，進(jìn)行人工排查

12.2 RabbitMQ如何保證消息的冪等性（防重）

1. 什么是冪等性：冪等性是指一次和多次請(qǐng)求某一資源，對(duì)資源本身響應(yīng)都有相同的結(jié)果。
2. 為什么消息會(huì)重復(fù)：消息被成功消費(fèi)，但是在A(yíng)CK時(shí)，機(jī)器宕機(jī)，導(dǎo)致消息MQ沒(méi)有收到ACK確認(rèn)，改消息會(huì)重新發(fā)給其他的消費(fèi)者，或者再重連后再次發(fā)送給改消費(fèi)者，造成消費(fèi)者重復(fù)消費(fèi)消息
3. 如何防止

• 消費(fèi)者設(shè)計(jì)一個(gè)全局唯一標(biāo)識(shí)，每次消費(fèi)的時(shí)候利用該唯一標(biāo)識(shí)進(jìn)行判斷該標(biāo)識(shí)對(duì)應(yīng)的消息是否已經(jīng)消費(fèi)過(guò)，這個(gè)標(biāo)識(shí)可以使用mysql的主鍵自增策略設(shè)計(jì)，也可以使用redis的原子性操作，setnx實(shí)現(xiàn)
• 使用樂(lè)觀(guān)鎖方式，在消息中攜帶version版本號(hào)，在數(shù)據(jù)庫(kù)執(zhí)行update語(yǔ)句時(shí)帶上version的條件，且每次update時(shí)，version + 1

12.3 RabbitMQ如何防止消息積壓

1. 導(dǎo)致消息積壓原因

• 消費(fèi)者宕機(jī)
• 消費(fèi)者消費(fèi)能力不足

2. 解決方案

• 上線(xiàn)更多的消費(fèi)者
• 上線(xiàn)專(zhuān)門(mén)的消息隊(duì)列服務(wù)，將消息批量取出，記錄到數(shù)據(jù)庫(kù)，然后離線(xiàn)慢慢處理

RabbitMQ是如何保證高可用的

通過(guò)集群+鏡像模式
集群模式可以解決單個(gè)RabbitMQ的壓力，但是宕機(jī)后，隊(duì)列上的內(nèi)容還是需要重啟后重試后保證隊(duì)列消息不丟，為了在隊(duì)列節(jié)點(diǎn)故障依然可以無(wú)重啟提供服務(wù)，可以創(chuàng)建鏡像，每次寫(xiě)入數(shù)據(jù)其他RabbitMQ服務(wù)都同步一份，即使有實(shí)例發(fā)生故障，剩余的實(shí)例也可以正常提供服務(wù)