1.大多應用中,可經過消息服務中間件來提高系統異步通訊、擴展解耦能力java
2.消息服務中兩個重要概念:web
消息代理(message broker)即消息服務器 和目的地(destination)spring
當消息發送者發送消息之後,將由消息代理接管,消息代理保證消息傳遞到指定目的地。docker
3.消息隊列主要有兩種形式的目的地數據庫
1.隊列(queue):點對點消息通訊(point-to-point)api
2.主題(topic):發佈(publish)/訂閱(subscribe)消息通訊瀏覽器
場景1:異步處理服務器
1)網絡
用戶依次執行,在150ms後獲得消息,缺點:發送時間很慢,發送郵件和註冊短信不是下一ms立馬執行的;多線程
2)
當用戶將信息寫入數據庫使用多線程方式併發執行兩種操做,時間相應100ms
3)
當用戶將消息寫進數據庫,可將要使用的信息寫入消息隊列(這個操做是很短的),而後立馬返回響應信息,用戶感知55ms後,發送郵件和發送短信能夠從消息隊列中異步讀取。
場景2:應用解耦
可將兩個系統抽取出來,若是要使用將信息寫入消息隊列中,其餘的系統只負責取;
場景3:流量削峯
10萬人秒殺1w件商品,若是將全部的請求都處理,服務器會卡死,解決方法:用戶秒殺請求發送,直接進入消息隊列,可將消息設置爲定長,10w用戶誰快誰先進入隊列,進步了的立馬拋棄,至關於搶佔了一個座位,而後再進行下一步處理。。。
消息發送者發送消息,消息代理將其放入一個隊列中,消息接收者從隊列中獲取消息內容,消息讀取後被移出隊列
消息只有惟一的發送者和接受者,但並非說只能有一個接收者
注意:一旦B從消息隊列中取出信息,則理解會刪除,C、D、沒法接收到
發送者(發佈者)發送消息到主題,多個接收者(訂閱者)監聽(訂閱)這個主題,那麼就會在消息到達時同時收到消息
一、JMS(Java Message Service)JAVA消息服務:
基於JVM消息代理的規範。ActiveMQ、HornetMQ是JMS實現
二、AMQP(Advanced Message Queuing Protocol)
高級消息隊列協議,也是一個消息代理的規範,兼容JMS
RabbitMQ是AMQP的實現
對比:
JMS | AMQP | |
---|---|---|
定義 | Java api | 網絡線級協議 |
跨語言 | 否 | 是 |
跨平臺 | 否 | 是 |
Model | 提供兩種消息模型: (1)、Peer-2-Peer (2)、Pub/sub | 提供了五種消息模型: (1)、direct exchange (2)、fanout exchange (3)、topic change (4)、headers exchange (5)、system exchange 本質來說,後四種和JMS的pub/sub模型沒有太大差異,僅是在路由機制上作了更詳細的劃分; |
支持消息類型 | 多種消息類型: TextMessage MapMessage BytesMessage StreamMessage ObjectMessage Message (只有消息頭和屬性) | byte[] 當實際應用時,有複雜的消息,能夠將消息序列化後發送。 |
綜合評價 | JMS 定義了JAVA API層面的標準;在java體系中,多個client都可以經過JMS進行交互,不須要應用修改代碼,可是其對跨平臺的支持較差; | AMQP定義了wire-level層的協議標準;自然具備跨平臺、跨語言特性。 |
區別之一:兩種規範提供的消息通訊機制都是基於點對點和發佈訂閱式,只是AMQP將發佈訂閱又分爲4種, fanout exchange、topic change、headers exchange、system exchange
spring-jms:提供了對JM的支持
spring-rabbit:提供了對AMQP的支持
須要ConnectionFactory的實現來鏈接消息代理
提供JmsTemplate、RabbitTemplate來發送消息
兩個註解
@JmsListener(JMS)、
@RabbitListener(AMQP)註解在方法上監聽消息代理髮布的消息
前提要@EnableJms、@EnableRabbit開啓支持
Spring Boot自動配置
自動配置類
–JmsAutoConfiguration
–RabbitAutoConfiguration
RabbitMQ是一個由erlang開發的AMQP(Advanved Message Queue Protocol)的開源實現。
消息,消息是不具名的,它由消息頭和消息體組成。消息體是不透明的,而消息頭則由一系列的可選屬性組成,這些屬性包括routing-key(路由鍵)、priority(相對於其餘消息的優先權)、delivery-mode(指出該消息可能須要持久性存儲)等。
消息的生產者,也是一個向交換器發佈消息的客戶端應用程序。
交換器,用來接收生產者發送的消息並將這些消息路由給服務器中的隊列。
Exchange有4種類型:direct(默認),fanout, topic, 和headers,不一樣類型的Exchange轉發消息的策略有所區別
消息的消費者,表示一個從消息隊列中取得消息的客戶端應用程序。
虛擬主機,表示一批交換器、消息隊列和相關對象。虛擬主機是共享相同的身份認證和加密環境的獨立服務器域。每一個 vhost 本質上就是一個 mini 版的 RabbitMQ 服務器,擁有本身的隊列、交換器、綁定和權限機制。vhost 是 AMQP 概念的基礎,必須在鏈接時指定,RabbitMQ 默認的 vhost 是 / 。
表示消息隊列服務器實體
AMQP 中消息的路由過程和 Java 開發者熟悉的 JMS 存在一些差異,AMQP 中增長了 Exchange 和 Binding 的角色。生產者把消息發佈到 Exchange 上,消息最終到達隊列並被消費者接收,而 Binding 決定交換器的消息應該發送到那個隊列。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-09Ll3Gzs-1571051304979)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1571050571215.png)]
Exchange類型
**Exchange分發消息時根據類型的不一樣分發策略有區別,目前共四種類型:**direct、fanout、topic、headers。headers 匹配 AMQP 消息的 header 而不是路由鍵, headers 交換器和 direct 交換器徹底一致,但性能差不少,目前幾乎用不到了,因此直接看另外三種類型:
1)Direct Exchange
消息中的路由鍵(routing key)若是和 Binding 中的 binding key 一致,
交換器就將消息發到對應的隊列中。路由鍵與隊列名徹底匹配,若是一個隊列綁定到交換機要求路由鍵爲「dog」,則只轉發 routing key 標記爲「dog」的消息,不會轉發「dog.puppy」,也不會轉發「dog.guard」等等。它是徹底匹配、單播的模式。
2)Fanout Exchange
每一個發到 fanout 類型交換器的消息都會分到全部綁定的隊列上去。fanout
交換器不處理路由鍵,只是簡單的將隊列綁定到交換器上,每一個發送到交換器的消息都會被轉發到與該交換器綁定的全部隊列上。很像子網廣播,每臺子網內的主機都得到了一份複製的消息。fanout
類型轉發消息是最快的。
3)Topic Exchange
topic 交換器經過模式匹配分配消息的路由鍵屬性,將路由鍵和某個模式進行匹配,此時隊列須要綁定到一個模式上。它將路由鍵和綁定鍵的字符串切分紅單詞,這些單詞之間用點隔開。它一樣也會識別兩個通配符:符號「#」和符號「」。#匹配0個或多個單詞**,****匹配一個單詞。
下載:運行docker,輸入命令docker pull rabbitmq:management(帶有管理界面的RabbitMq)
docker pull rabbitmq:management
查看rabbitmq:
啓動:**
docker上安裝rabbitmq帶界面的,manangment, (有兩個端口)
5672:主機的5672映射到容器的5672
15672:管理界面訪問web界面的
啓動rabbitmq
docker run -d -p 5672:5672 -p 15672:15672 --name myrabbitmq 27764c8758a0
查看運行的容器:
瀏覽器訪問:
這裏密碼用戶名爲guest
基於下圖進行測試:
建立交換器(exchange)
添加消息隊列(queues)
Binding規則
測試發送消息
1)dircet Exchange
queue接受到消息:
2)fanout exchange
每一個隊列都能收到消息
3)topic exchange
根據匹配規則接收