1.安裝Rabbit,參考（https://www.cnblogs.com/ericli-ericli/p/5902270.html）
2.進入http://localhost:15672，賬戶密碼都是 guest
3.新建一個消息隊列
Durability：選擇Transient。
4.新建一個交換機exchange
解釋① 這個是消息隊列的名字 queue1 。
② Routing key 正則表達式去匹配對應的key，從頭開始匹配
5.java代碼實現
（1）在pom文件引入jar包
<!-- 添加springboot對amqp的支持 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
（2）新建2個SpeingBoot項目 receive、sender
在啓動項加註解 @EnableRabbit；
在配置文件加配置：
spring:
application:
name: sender
rabbitmq:
host: 127.0.0.1
port: 5672
username: guest
password: guest
新建發送類
import org.springframework.amqp.core.AmqpTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class HelloSender {
@Autowired
private AmqpTemplate amqpTemplate;
public void send(String va){
amqpTemplate.convertAndSend("queue","queue",va);
System.out.print("OK");
}
}
備註：convertAndSend中3個參數的含義，第一個是交換機的名字，第二個是對應Routing key 的值（有可能第二個參數是queue123，Routing key 的值也可以是queue,因爲是正則表達式從頭匹配的，不同的策略不同的計算方法），第三個是消息內容
（3）新建測試類
@SpringBootTest(classes = SenderApplication.class)
@RunWith(SpringJUnit4ClassRunner.class)
public class TestRabbitMQ {
@Autowired
private HelloSender helloSender;
@Test
public void testRabbit() {
helloSender.send("wdwdwd12312s");
}
}
至此發送端簡單發送成功
（4）在receive項目中引入jar包，啓動項加註解，和發送端相同；
新建監聽消息隊列接口
import org.springframework.amqp.rabbit.annotation.RabbitListener;
import org.springframework.stereotype.Component;
@Component
public class HelloReceive {
@RabbitListener(queues = "queue1")
public void processC(String str) {
System.out.println("Receive:"+str);
}
}
至此整個簡單的發送和接收都能起作用。
至於Rebbit的基本知識可以百度
6.RabbitMQ是通過Binding將Exchange和Queue鏈接在一起，這樣Exchange就知道如何將消息準確的推送到Queue中去
7.在綁定（Binding）Exchange和Queue的同時，一般會指定一個Binding Key，生產者將消息發送給Exchange的時候，一般會產生一個Routing Key，當Routing Key和Binding Key對應上的時候，消息就會發送到對應的Queue中去。那麼Exchange有四種類型，不同的類型有着不同的策略。也就是表明不同的類型將決定綁定的Queue不同，換言之就是說生產者發送了一個消息，Routing Key的規則是A，那麼生產者會將Routing Key=A的消息推送到Exchange中，這時候Exchange中會有自己的規則，對應的規則去篩選生產者發來的消息，如果能夠對應上Exchange的內部規則就將消息推送到對應的Queue中去。那麼接下來就來詳細講解下Exchange裏面類型。
Exchange Type
我來用表格來描述下類型以及類型之間的區別。
- fanout
fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。
上圖所示，生產者（P）生產消息1將消息1推送到Exchange，由於Exchange Type=fanout這時候會遵循fanout的規則將消息推送到所有與它綁定Queue，也就是圖上的兩個Queue最後兩個消費者消費。
- direct
direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中
當生產者（P）發送消息時Rotuing key=booking時，這時候將消息傳送給Exchange，Exchange獲取到生產者發送過來消息後，會根據自身的規則進行與匹配相應的Queue，這時發現Queue1和Queue2都符合，就會將消息傳送給這兩個隊列，如果我們以Rotuing key=create和Rotuing key=confirm發送消息時，這時消息只會被推送到Queue2隊列中，其他Routing Key的消息將會被丟棄。
- topic
前面提到的direct規則是嚴格意義上的匹配，換言之Routing Key必須與Binding Key相匹配的時候纔將消息傳送給Queue，那麼topic這個規則就是模糊匹配，可以通過通配符滿足一部分規則就可以傳送。它的約定是：
- routing key爲一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
- binding key與routing key一樣也是句點號“. ”分隔的字符串
- binding key中可以存在兩種特殊字符“*”與“#”，用於做模糊匹配，其中“*”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
當生產者發送消息Routing Key=F.C.E的時候，這時候只滿足Queue1，所以會被路由到Queue中，如果Routing Key=A.C.E這時候會被同是路由到Queue1和Queue2中，如果Routing Key=A.F.B時，這裏只會發送一條消息到Queue2中。
- headers
headers類型的Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。
在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。
該類型的Exchange沒有用到過（不過也應該很有用武之地），所以不做介紹。
這裏在對其進行簡要的表格整理：
| 類型名稱 | 類型描述 |
| fanout | 把所有發送到該Exchange的消息路由到所有與它綁定的Queue中 |
| direct | Routing Key==Binding Key |
| topic | 我這裏自己總結的簡稱模糊匹配 |
| headers | Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。 |
補充說明：
ConnectionFactory、Connection、Channel
ConnectionFactory、Connection、Channel都是RabbitMQ對外提供的API中最基本的對象。Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。ConnectionFactory爲Connection的製造工廠。
Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。
Connection就是建立一個TCP連接，生產者和消費者的都是通過TCP的連接到RabbitMQ Server中的，這個後續會再程序中體現出來。
Channel虛擬連接，建立在上面TCP連接的基礎上，數據流動都是通過Channel來進行的。爲什麼不是直接建立在TCP的基礎上進行數據流動呢？如果建立在TCP的基礎上進行數據流動，建立和關閉TCP連接有代價。頻繁的建立關閉TCP連接對於系統的性能有很大的影響，而且TCP的連接數也有限制，這也限制了系統處理高併發的能力。但是，在TCP連接中建立Channel是沒有上述代價的。