您现在的位置是:Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款 > 

01 java 發布訂閱模式(消息隊列原理及選型)

Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款2024-05-22 03:05:59【】1人已围观

简介消息隊列原理及選型消息隊列(MessageQueue)是一種進程間通信或同一進程的不同線程間的通信方式。Broker(消息服務器)Broker的概念來自與ApacheActiveMQ,通俗的講就是MQ

消息隊列原理及選型

消息隊列(Message Queue)是一種進程間通信或同一進程的不同線程間的通信方式。

Broker(消息服務器)

Broker的概念來自與Apache ActiveMQ,通俗的講就是MQ的服務器。

Procer(生產者)

業務的發起方,負責生產消息傳輸給broker

Consumer(消費者)

業務的處理方,負責從broker獲取消息并進行業務邏輯處理

Topic(主題)

發布訂閱模式下的消息統一匯集地,不同生產者向topic發送消息,由MQ服務器分發到不同的訂閱 者,實現消息的廣播

Queue(隊列)

PTP模式下,特定生產者向特定queue發送消息,消費者訂閱特定的queue完成指定消息的接收。

Message(消息體)

根據不同通信協議定義的固定格式進行編碼的數據包,來封裝業務數據,實現消息的傳輸

點對點模型用于消息生產者和消息消費者之間點到點的通信。

點對點模式包含三個角色:

每個消息都被發送到一個特定的隊列,接收者從隊列中獲取消息。隊列保留著消息,可以放在內存 中也可以持久化,直到他們被消費或超時。

特點:

發布訂閱模型包含三個角色:

多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

特點:

AMQP即Advanced Message Queuing Proto買粉絲l,是應用層協議的一個開放標準,為面向消息的中間件設計。消息中間件主要用于組件之間的解耦,消息的發送者無需知道消息使用者的存在,反之亦然。AMQP 的主要特征是面向消息、隊列、路由(包括點對點和發布/訂閱)、可靠性、安全。

優點:可靠、通用

MQTT(Message Queuing Telemetry Transport,消息隊列遙測傳輸)是IBM開發的一個即時通訊協議,有可能成為物聯網的重要組成部分。該協議支持所有平臺,幾乎可以把所有聯網物品和外部連接起來,被用來當做傳感器和致動器(比如通過Twitter讓房屋聯網)的通信協議。

優點:格式簡潔、占用帶寬小、移動端通信、PUSH、嵌入式系統

STOMP(Streaming Text Orientated Message Proto買粉絲l)是流文本定向消息協議,是一種為MOM(Message Oriented Middleware,面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式,允許客戶端與任意STOMP消息代理(Broker)進行交互。

優點:命令模式(非topic\queue模式)

XMPP(可擴展消息處理現場協議,Extensible Messaging and Presence Proto買粉絲l)是基于可擴展標記語言(XML)的協議,多用于即時消息(IM)以及在線現場探測。適用于服務器之間的準即時操作。核心是基于XML流傳輸,這個協議可能最終允許因特網用戶向因特網上的其他任何人發送即時消息,即使其操作系統和瀏覽器不同。

優點:通用公開、兼容性強、可擴展、安全性高,但XML編碼格式占用帶寬大

RabbitMQ 是實現 AMQP(高級消息隊列協議)的消息中間件的一種,最初起源于金融系統,用于在分布式系統中存儲轉發消息,在易用性、擴展性、高可用性等方面表現不俗。 RabbitMQ 主要是為了實現系統之間的雙向解耦而實現的。當生產者大量產生數據時,消費者無法快速消費,那么需要一個中間層。保存這個數據。

RabbitMQ 是一個開源的 AMQP 實現,服務器端用Erlang語言編寫,支持多種客戶端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等,支持 AJAX。用于在分布式系統中存儲轉發消息,在易用性、擴展性、高可用性等方面表現不俗。

Channel(通道)

道是兩個管理器之間的一種單向點對點的的通信連接,如果需要雙向交流,可以建立一對通道。

Exchange(消息交換機)

Exchange類似于數據通信網絡中的交換機,提供消息路由策略。

RabbitMq中,procer不是通過信道直接將消息發送給queue,而是先發送給Exchange。一個Exchange可以和多個Queue進行綁定,procer在傳遞消息的時候,會傳遞一個ROUTING_KEY,Exchange會根據這個ROUTING_KEY按照特定的路由算法,將消息路由給指定的queue。和Queue一樣,Exchange也可設置為持久化,臨時或者自動刪除。

Exchange有4種類型:direct(默認),fanout, topic, 和headers。

不同類型的Exchange轉發消息的策略有所區別:

Binding(綁定)

所謂綁定就是將一個特定的 Exchange 和一個特定的 Queue 綁定起來。Exchange 和Queue的綁定可以是多對多的關系。

Routing Key(路由關鍵字)

exchange根據這個關鍵字進行消息投遞。

vhost(虛擬主機)

在RabbitMq server上可以創建多個虛擬的message broker,又叫做virtual hosts (vhosts)。每一個vhost本質上是一個mini-rabbitmq server,分別管理各自的exchange,和bindings。vhost相當于物理的server,可以為不同app提供邊界隔離,使得應用安全的運行在不同的vhost實例上,相互之間不會干擾。procer和買粉絲nsumer連接rabbit server需要指定一個vhost。

假設P1和C1注冊了相同的Broker,Exchange和Queue。P1發送的消息最終會被C1消費。

基本的通信流程大概如下所示:

Consumer收到消息時需要顯式的向rabbit broker發送basic。ack消息或者買粉絲nsumer訂閱消息時設置買粉絲_ack參數為true。

在通信過程中,隊列對ACK的處理有以下幾種情況:

即消息的Ackownledge確認機制,為了保證消息不丟失,消息隊列提供了消息Acknowledge機制,即ACK機制,當Consumer確認消息已經被消費處理,發送一個ACK給消息隊列,此時消息隊列便可以刪除這個消息了。如果Consumer宕機/關閉,沒有發送ACK,消息隊列將認為這個消息沒有被處理,會將這個消息重新發送給其他的Consumer重新消費處理。

消息的收發處理支持事務,例如:在任務中心場景中,一次處理可能涉及多個消息的接收、處理,這應該處于同一個事務范圍內,如果一個消息處理失敗,事務回滾,消息重新回到隊列中。

消息的持久化,對于一些關鍵的核心業務來說是非常重要的,啟用消息持久化后,消息隊列宕機重啟后,消息可以從持久化存儲恢復,消息不丟失,可以繼續消費處理。

fanout 模式

模式特點:

direct 模式

任何發送到Direct Exchange的消息都會被轉發到routing_key中指定的Queue。

如果一個exchange 聲明為direct,并且bind中指定了routing_key,那么發送消息時需要同時指明該exchange和routing_key。

簡而言之就是:生產者生成消息發送給Exchange, Exchange根據Exchange類型和basic_publish中的routing_key進行消息發送 消費者:訂閱Exchange并根據Exchange類型和binding key(bindings 中的routing key) ,如果生產者和訂閱者的routing_key相同,Exchange就會路由到那個隊列。

topic 模式

前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key,但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。

topic類型的Exchange在匹配規則上進行了擴展,它與direct類型的Exchage相似,也是將消息路由到binding key與routing key相匹配的Queue中,但這里的匹配規則有些不同。

它約定:

以上圖中的配置為例,routingKey=”quick.orange.rabbit”的消息會同時路由到Q1與Q2,routingKey=”lazy.orange.fox”的消息會路由到Q1,routingKey=”lazy.brown.fox”的消息會路由到Q2,routingKey=”lazy.pink.rabbit”的消息會路由到Q2(只會投遞給Q2一次,雖然這個routingKey與Q2的兩個bindingKey都匹配);routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息將會被丟棄,因為它們沒有匹配任何bindingKey。

RabbitMQ,部署分三種模式:單機模式,普通集群模式,鏡像集群模式。

普通集群模式

多臺機器部署,每個機器放一個rabbitmq實例,但是創建的queue只會放在一個rabbitmq實例上,每個實例同步queue的元數據。

如果消費時連的是其他實例,那個實例會從queue所在實例拉取數據。這就會導致拉取數據的開銷,如果那個放queue的實例宕機了,那么其他實例就無法從那個實例拉取,即便開啟了消息持久化,讓rabbitmq落地存儲消息的話,消息不一定會丟,但得等這個實例恢復了,然后才可以繼續從這個queue拉取數據, 這就沒什么高可用可言,主要是提供吞吐量 ,讓集群中多個節點來服務某個queue的讀寫操作。

鏡像集群模

很赞哦!(66)

Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款的名片

职业:程序员,设计师

现居:湖南衡阳石鼓区

工作室:小组

Email:[email protected]