RabbitMQ指南之三:釋出/訂閱模式(Publish/Subscribe)
在上一章中,我們建立了一個工作佇列,工作佇列模式的設想是每一條訊息只會被轉發給一個消費者。本章將會講解完全不一樣的場景: 我們會把一個訊息轉發給多個消費者,這種模式稱之為釋出-訂閱模式。
為了闡述這個模式,我們將會搭建一個簡單的日誌系統,它包含兩種程式:一種傳送日誌訊息,另一種接收並列印日誌訊息。在這個日誌系統裡,每一個執行的消費者都可以獲取到訊息,在這種情況下,我們可以實現這種需求:一個消費者接收訊息並寫入磁碟,另一個消費者接收訊息並列印在電腦螢幕上。簡單來說,生產者釋出的訊息將會以廣播的形式轉發到所有的消費者。
1、交換器(Exchange)
在前兩章節我們,我們往佇列中釋出訊息或獲取訊息,然而,前面的講解其實並不完整,接下來,是時候介紹完整的RabbitMq訊息模型了。
回憶一下我們前兩章指南中包含的內容:
-
- 一個生產者用以傳送訊息;
- 一個佇列快取訊息;
- 一個消費者用以消費佇列中的訊息。
RabbitMq訊息模式的核心思想是:一個生產者並不會直接往一個佇列中傳送訊息,事實上,生產者根本不知道它傳送的訊息將被轉發到哪些佇列。
實際上,生產者只能把訊息傳送給一個exchange,exchange只做一件簡單的事情:一方面它們接收從生產者傳送過來的訊息,另一方面,它們把接收到的訊息推送給佇列。一個exchage必須清楚地知道如何處理一條訊息。
有四種類型的交換器,分別是:direct、topic、headers、fanout。本章主要講解最後一種:fanous(廣播模式)。下面建立一個fanout型別的交換器,我們稱之為:logs:
1 channel.exchangeDeclare("logs", "fanout");
廣播模式交換器很簡單,從字面意思也能理解,它其實就是把接收到的訊息推送給所有它知道的佇列。在我們的日誌系統中正好需要這種模式。
如果想檢視當前系統中有多少個exchange,可以使用以下命令:
sudo rabbitmqctl list_exchanges
或者通過控制檯檢視:
可以看到有很多以amq.*開頭的交換器,以及(AMQP default)預設交換器,這些是預設建立的交換器。
在前面兩章的指南中,我們並不知道交換器的存在,但是依然可以將訊息傳送到佇列中,那其實並不是因為我們可以不使用交換器,實際上是我們使用了預設的交換器(我們通過指定交換器為字字串:""),回顧一下我們之前是如何傳送訊息的:
1 channel.basicPublish("", "hello", null, message.getBytes());
第一個引數是交換器的名字,空字串表示它是一個預設或無命名的交換器,訊息將會由指定的路由鍵(第二個引數,routingKey,後面會講)轉發到佇列。
你可能會有疑問:既然exchange可以指定為空字串(""),那麼可否指定為null?
答案是:不能!
通過跟蹤釋出訊息的程式碼,在AMQImpl類中的Publish()方面中,可以看到,不光是exchange不能為null,同時routingKey路由鍵也不能為null,否則會丟擲異常:
接著上面的講解,我們建立一個命名的交換器:
1 channel.basicPublish( "logs", "", null, message.getBytes());
2、臨時佇列
在前兩章的例子中,我們使用的佇列都是有具體的佇列名,建立命名佇列是很必要的,因為我們需要將消費者指向同一名字的佇列。因此,要想在生產者和消費者中間共享佇列就必須要使用命名佇列。
但是,本章講解的日誌系統也可以使用非命名佇列(可以不手動命名),我們希望收到所有日誌訊息,而不是部分。並且我們希望總是接收到新的日誌訊息而不是舊的日誌訊息。為了解決這個問題,需要分兩步走。
首先,無論何時我們的消費者連線到RabbitMq,我們都需要一個新的、空的佇列來接收日誌訊息,因此,消費者在連線上RabbitMq之後需要建立一個任意名字的佇列,或者讓RabbitMq生成任意的佇列名字。
其次,一旦該消費者斷開了與RabbitMq的連線,佇列也被自動刪除。
通過JAVA客戶端的無參方法:queueDeclare()來建立一個非持久化、專有的、自動刪除的、名字隨機生成的佇列。
1 String queueName = channel.queueDeclare().getQueue();
3、繫結(Binding)
前面廣播模式的交換器和佇列已經建立好了,接下來就是要告訴交換器向佇列裡傳送訊息。交換器與佇列之間的關係稱之為繫結關係。
1 channel.queueBind(queueName, "logs", "");
至此,交換器已經可以往佇列中傳送訊息了。
可以通過下列命令來檢視佇列的繫結關係:
4、完整的程式碼
EmitLog.java
1 import com.rabbitmq.client.BuiltinExchangeType;
2 import com.rabbitmq.client.Channel;
3 import com.rabbitmq.client.Connection;
4 import com.rabbitmq.client.ConnectionFactory;
5
6 public class EmitLog {
7
8 private static final String EXCHANGE_NAME = "logs";
9
10 public static void main(String[] args) throws Exception {
11
12 ConnectionFactory factory = new ConnectionFactory();
13 factory.setHost("192.168.92.130");
14
15 try (Connection connection = factory.newConnection();
16 Channel channel = connection.createChannel();) {
17
18 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT);
19
20 String message = "RabbitMq fanout。。。。。。";
21 channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes("utf-8"));
22
23 System.out.println(" [x] Sent '" + message + "'");
24 }
25 }
26 }
正好你所看到的,Connection建立完成之後,定義了exchange,這一步是必要的,因為如果沒有交換器將無法傳送訊息。
如此沒有佇列繫結到該交換器上,那麼,交換器收到的訊息將會丟失,但是對我們本章的日誌系統來說沒問題的,當沒有消費者時,我們可以安全地放棄掉資料,我們只接收最新的日誌訊息。
ReceiveLogs.java
1 public class ReceiveLogs {
2
3 private static final String EXCHANGE_NAME = "logs";
4
5 public static void main(String[] args) throws Exception {
6
7 ConnectionFactory factory = new ConnectionFactory();
8 factory.setHost("192.168.92.130");
9
10 Connection connection = factory.newConnection();
11 Channel channel = connection.createChannel();
12
13 channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.FANOUT);
14
15 final String queue = channel.queueDeclare().getQueue();
16 channel.queueBind(queue,EXCHANGE_NAME,"");
17
18 System.out.println(" [*] Waiting for messages. To exit press CTRL+C");
19
20 DeliverCallback deliverCallback = (consumerTa,delivery) -> {
21
22 String message = new String(delivery.getBody(), "UTF-8");
23 System.out.println(" [x] Received '" + message + "'");
24
25 };
26
27 channel.basicConsume(queue,true,deliverCallback,consumerTag -> {});
28 }
29 }
這裡的autoAck設定為true,因為我們這裡是廣播模式,每個消費者都會收到一樣的訊息,並且這裡給消費者生產的隨機名稱的佇列相當於是獨有的,所以在接收到訊息之後立即傳送確認回執是OK的。
但是這裡先提出一個疑問:在這種模式下,每個佇列收到的訊息是否也會有Ready和Unacked狀態?
5、測試結果
一、首先啟動生產者,再啟動兩個消費者
可以看到,生產者啟動後傳送的訊息丟失了,兩個消費者並沒有消費到,此時再看控制檯:
可見RabbitMq為我們建立了兩個隨機命名的佇列,其Exclusive是Owner,表示是專有的,Parameters為AD(auto delete),擁有該佇列的消費者一占斷開連線,佇列將會被自動刪除。
二、其次啟動生產者傳送一次訊息
兩個消費都都收到了訊息。
三、關閉所有消費者,觀察控制檯變化
兩個專有隨機佇列自動刪除了。
6、SpringBoot的實現
工程結構圖:
一、配置檔案application.properties:
生產者:
#RabbitMq
spring.rabbitmq.host=192.168.92.130
spring.rabbitmq.exchange=logs
消費者:
#RabbitMq
spring.rabbitmq.host=192.168.92.130
spring.rabbitmq.exchange=logs
##佇列--我們可以自己指定佇列名稱,也可以由RabbitMq自動生成,這裡為了方便,我們自己命名(如果需要,我也可以寫一個自動生成名稱的方法)
rqbbitmq.log.fanout.info=info
rqbbitmq.log.fanout.error=error
server.port=8090
二、生產者程式碼
這裡為了讓系統生產者啟動時就自動傳送一條訊息,我加了一個EmitLogRunner類。
EmitLog.java
1 import org.springframework.amqp.core.AmqpTemplate;
2 import org.springframework.beans.factory.annotation.Autowired;
3 import org.springframework.beans.factory.annotation.Value;
4 import org.springframework.stereotype.Component;
5
6 @Component
7 public class EmitLog {
8
9 @Value("${spring.rabbitmq.exchange}")
10 private String exchange;
11
12 @Autowired
13 private AmqpTemplate amqpTemplate;
14
15 public void send(String msg) {
16 amqpTemplate.convertAndSend(exchange,"",msg);
17 }
18 }
EmitLogRunner.java
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;
@Component
public class EmitLogRunner implements ApplicationRunner {
@Autowired
private EmitLog emitLog;
@Override
public void run(ApplicationArguments args) throws Exception {
System.out.println("生產者釋出訊息:" + msg);
emitLog.send("RabbitMq fanout test message");
}
}
二、消費者程式碼
ReceiveInfoLogs.java
@Component
@RabbitListener(
bindings = @QueueBinding(
value = @Queue(value = "${rqbbitmq.log.fanout.info}",autoDelete = "true"),
exchange = @Exchange(value = "${spring.rabbitmq.exchange}",type = ExchangeTypes.FANOUT)
)
)
public class ReceiveInfoLogs {
@Autowired
private AmqpTemplate amqpTemplate;
@RabbitHandler
public void receiveInfoLog (Object message) {
System.out.println("接收到info級別的日誌:" + message);
}
}
ReceiveErrorLogs.java
import org.springframework.amqp.core.AmqpTemplate;
import org.springframework.amqp.core.ExchangeTypes;
import org.springframework.amqp.rabbit.annotation.*;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
@RabbitListener(
bindings = @QueueBinding(
value = @Queue(value = "${rqbbitmq.log.fanout.error}",autoDelete = "true"),
exchange = @Exchange(value = "${spring.rabbitmq.exchange}",type = ExchangeTypes.FANOUT)
)
)
public class ReceiveErrorLogs {
@Autowired
private AmqpTemplate amqpTemplate;
@RabbitHandler
public void receiveErrorLog(Object message) {
System.out.println("接收到的error級別日誌:" + message);
}
}
注意看一下註解方式bindings裡面都是以@開頭並加上對應的要繫結的項,琢磨一下應該都能理解。
三、驗證
啟動消費者和生產者,檢視控制檯:
點關注,不迷路,這是一個程式設計師都想要關注的公眾號
相關推薦
RabbitMQ指南之三:釋出/訂閱模式(Publish/Subscribe)
在上一章中,我們建立了一個工作佇列,工作佇列模式的設想是每一條訊息只會被轉發給一個消費者。本章將會講解完全不一樣的場景: 我們會把
RabbitMQ的釋出訂閱模式(Publish/Subscribe)
### 一、釋出/訂閱(Publish/Subscribe)模式 釋出訂閱是我們經常會用到的一種模式,生產者生產訊息後,所有訂閱者都可以收到。RabbitMQ的釋出/訂閱模型圖如下: ![](https://img2020.cnblogs.com/blog/653404/202005/653404-20200
RabbitMQ指南之三:發布/訂閱模式(Publish/Subscribe)
問題 除了 消息 模型 server fan 以及 color let 在上一章中,我們創建了一個工作隊列,工作隊列模式的設想是每一條消息只會被轉發給一個消費者。本章將會講解完全不一樣的場景: 我們會把一個消息轉發給多個消費者,這種模式稱之為發布-訂閱模式。 為了
RabbitMQ學習第三記:發布/訂閱模式(Publish/Subscribe)
font image 直接 email err spl 回調方法 byte [] 工作隊列模式是直接在生產者與消費者裏聲明好一個隊列,這種情況下消息只會對應同類型的消費者。 舉個用戶註冊的列子:用戶在註冊完後一般都會發送消息通知用戶註冊成功(失敗)。如果在一個系統中
RabbitMQ指南之五:主題交換器(Topic Exchange)
vmw 有效 組成 oot alt basic env serve .com 在上一章中,我們完善了我們的日誌系統,用direct交換器替換了fanout交換器,使得我們可以有選擇性地接收消息。盡管如此,仍然還有限制:不能基於多個標準進行路由。在我們的日誌系統中,我們可
RabbitMQ系列教程之三:釋出\/訂閱(Publish\/Subscribe)
在前一個教程中,我們建立了一個工作佇列。工作佇列背後的假設是每個任務會被交付給一個【工人】。在這一部分我們將做一些完全不同的事情--我們將向多個【消費者】傳遞資訊。這種模式被稱為“釋出/訂閱”。 為了說明這種模式,我們將構建一個簡單的日誌系統。它將包括兩個程式,第一個將發
ActiveMQ入門系列三:釋出/訂閱模式
在上一篇《ActiveMQ入門系列二:入門程式碼例項(點對點模式)》中提到了ActiveMQ中的兩種模式:點對點模式(PTP)和釋出/訂閱模式(Pub & Sub),詳細介紹了點對點模式並用程式碼例項進行說明,今天就介紹下發布/訂閱模式。 一、理論基礎 釋出/訂閱模式的工作示意圖: 訊息
設計模式之三:單例模式(餓漢式與懶漢式)
//保證類在記憶體中只有一個物件 package com.xjh.demo.designpattern.pattern3; public class Student { private Student(){ } //懶漢式 priva
前端非同步程式設計系列之事件釋出/訂閱模式(2/4)
上一篇文章中,主要是介紹了什麼是非同步程式設計,而這從這篇文章開始,我會介紹一些非同步程式設計的一些解決方案。 目前非同步程式設計的解決方案主要有一下幾種: 1.事件釋出/訂閱模式 2.Promise/Deferred模式 3.流程控制庫 而我們這一篇文章主要是介紹第一種,即事件
觀察者模式(Publish/Subscribe)(C#實現)
轉載自 1. 概述 有時被稱作釋出/訂閱模式,觀察者模式定義了一種一對多的依賴關係,讓多個觀察者物件同時監聽某一個主題物件。這個主題物件在狀態發生變化時,會通知所有觀察者物件,使它們能夠自動更新自己。 2. 解決的問題 將一個系統分割成一個一些類相互協作的
RabbitMQ系列教程之三:發布/訂閱(Publish/Subscribe)
mqc 標題 整合 參數 cti 事情 return 控制臺 run (本教程是使用Net客戶端,也就是針對微軟技術平臺的) 在前一個教程中,我們創建了一個工作隊列。工作隊列背後的假設是每個任務會被交付給一個【工人】。在這一部分我們將做一些完全不同的事情--我們將向多個
RabbitMQ使用教程(四):釋出/訂閱模式—Publish/Subscribe
一、釋出/訂閱模式說明 今天我們來學習一點新的東西,之前我們是將一個訊息傳送給了一個特定的消費者,今天的做法完全不同,不再發送給某一個消費者,而是將一個訊息傳送給多個消費者,這便是:釋出/訂閱模式。 我們將使用該模式來實現一個日誌系統:一個程式產生日誌,一個
Spark程式設計指南之三:RDD基本概念
RDD是什麼? RDD(Resilient Distributed Dataset),彈性分散式資料集,是Spark的核心資料結構抽象。 它是彈性的,具有容錯能力,能夠重新計算失敗結點。 它是分散式的,資料分佈在多個結點上。 它是一個數據集,可以從外部載入資料,可以是文字檔案,JSON,
介面內的:釋出 / 訂閱模式,生產 / 消費模式
到底哪一種更適合呢? 1、釋出 / 訂閱 模式的初始設立,和概念更為繁雜;它的呼叫迴路並不直接 2、生產 / 消費 模式,相對直觀明瞭;Add, Get, Consume then remove 3、釋出 / 訂閱 模式能夠製造強大的介面更新,適合於複雜的介面需求; 4、生產 / 消費 模式容易實現,
RabbitMQ官方中文入門教程(PHP版) 第三部分:釋出/訂閱(Publish/Subscribe)
1 $exchange->setName('logs'); 2 $exchange->setType(AMQP_EX_TYPE_FANOUT); 3 $exchange->declare(); fanout交換器很簡單,你可能從名字上就能猜測出來,它把訊息傳送給它所知道
設計模式之三:工廠方法模式—多型工廠的實現
簡單工廠的嚴重問題: 當系統中需要引進新產品時,靜態工廠方法通過所傳入引數的不同來建立不同的產品,這必定要修改工廠類的原始碼,違背了開閉原則 引入工廠方法模式: 針對不同的產品提供不同的工廠 定義: 定義一個用於建立物件的介面,讓子類決定將 哪一個類例項化,工廠方法迷失
rabbitmq官方教程之釋出與訂閱(Publish/Subscribe)
(using the Java Client) 在上一篇工作佇列中中我們已經建立了一個工作佇列。工作佇列背後的假設是每個任務都交付給一個worker。 在這部分中,我們會做一些完全不同的事情 - 我們會向多個消費者傳遞資訊。這種模式被稱為“釋出/訂閱”。
hadoop初識之三:搭建hadoop環境(配置HDFS,Yarn及mapreduce 執行在yarn)上及三種執行模式(本地模式,偽分散式和分散式介)
--===============安裝jdk(解壓版)================== --root 使用者登入 --建立檔案層級目錄 /opt下分別 建 modules/softwares/datas/tools 資料夾 --檢視是否安裝jdk rpm -
Java中的設計模式 - 觀察者模式【又叫:釋出/訂閱模式】
文章目錄 Java中的設計模式 - 觀察者模式【又叫:釋出/訂閱模式】 1、觀察者模式是為了解決什麼問題 2、核心邏輯 3、優點 4、缺點 5、應用場景
設計模式系列之三:抽象工廠模式
前言 在設計模式有三個模式是與工廠模式相關的,分別是:簡單工廠模式、工廠方法模式以及抽象工廠模式。在前面的文章中已經談到前面兩種,這裡就對抽象工廠模式介紹一下。抽象工廠模式就是提供一個建立一系列相關或者相互依賴的介面(也就是抽象類),而無需指定具體的類。簡單來