訊息佇列高手課 基礎篇

2022-05-19 17:42:50 字數 2721 閱讀 8767

【訊息佇列高手課】- 基礎篇

訊息佇列都有哪些選擇:

rabbitmq - 特色:exchange模組,開箱即用

rocketmq - 特色:低延遲和金融級的穩定性

kafka - 特色:海量,非同步批量,「先攢一波再一起處理」

activemq:佇列模型和發布-訂閱模型都支援

zeromq

pulsar - 特色:儲存與計算分離

1.佇列模型

佇列:先進先出的線性表。因為這個特性故而訊息必須嚴格有序。按照什麼順序寫到佇列中就按照什麼順序讀出去。

2.發布 - 訂閱模型(publish-subscribe pattern)

如果有多個訊息者怎麼辦?使用發布-訂閱模型解決這個問題

在發布-訂閱模型中,訊息的傳送方稱為發布者,訊息的接收方稱為訂閱者,服務端存放訊息的容器稱為主題。發布者將訊息發布到主題中,訂閱者在接收訊息之前需要先「訂閱主題」,「訂閱」在這裡既是乙個動作,同時,也可以認為是主題在消費的時的乙個邏輯副本,每份訂閱中,訂閱者都能接收主題的所有訊息。

佇列模型和發布-訂閱模型的最大區別是:乙份訊息資料能不能被消費多次。

rabbitmq 的訊息模型

rabbitmq還是在堅持使用佇列模型,exchange模組放置在生產者和佇列之間,生產者不關係發給哪個佇列,而是把訊息傳送給exchange模組,由exchange上配置的策略決定將訊息投遞到哪些佇列中。

同乙份訊息如果要被多個消費者消費,就需要配置exchange將訊息放入對個佇列,每個佇列中都會有乙份完整的資料,為消費者提供服務

rocketmq 的訊息模型

rocketmq使用的是標準的發布-訂閱模型,但是,在 rocketmq 也有佇列(queue)這個概念,佇列的作用是什麼呢?這裡先說下訊息佇列的消費機制

訊息佇列的消費機制:

「請求 - 確認」機制,確保訊息不會在傳遞過程中由於網路或者伺服器故障丟失。

做法:在生產端,生產者先將訊息傳送給服務端,也就是broker,服務端在收到訊息並將訊息寫入主題或者佇列後,會給生產者傳送確認的響應。如果生產者沒有收到服務端的確認或者收到失敗額響應,則會重新傳送訊息;在消費端,消費者在收到訊息並完成自己的業務邏輯後也會給服務端傳送消費成功的確認,服務端只有收到訊息確認後,才認為一條訊息被成功消費,否則他就給消費者重新傳送訊息,直到對應的消費成功確認。這個機制保證了訊息傳遞過程中的可靠性。

如何通過水平擴充套件消費者數量來提公升消費端總體的消費效能?

每個主題包含多個佇列,通過佇列來實現多例項並行生產和消費。rocketmq只保證佇列上訊息的有序性,主題層面是無法保證訊息的嚴格順序的。

rocketmq中訂閱者的概念是通過消費組(consumer group)來體現的。每個消費組消費主題中的乙份完整訊息,不同消費組之前消費進度彼此不受影響。消費組中包含多個消費者,一條訊息只被乙個消費者消費。

kafka的訊息模型

kafka的訊息模型跟rocket是完全一樣的,也是發布訂閱模型,只是kafka中的佇列的名字為分割槽

另:消費者組和佇列數沒有關係。佇列數量可以根據資料量和消費速度配置。

rocketmq的分布式事務處理流程:

對於第4步中,如果commit失敗,kafka的解決方案為直接丟擲異常。

事務:4 個屬性(acid):原子性、一致性、隔離性、永續性

mqtt協議-三種傳遞訊息時能夠提供的服務質量標準:

預防訊息積壓如何處理:

傳送端:增加每次傳送訊息的批量大小,增加併發

消費端:優化消費業務邏輯;水平擴容;增加消費端的併發數

特別需要注意的一點是,在擴容 consumer 的例項數量的同時,必須同步擴容主題中的分割槽(也叫佇列)數量,確保 consumer 的例項數和分割槽數量是相等的。

課後題:

消費組和訊息位置有關係,消費者和消費位置是沒有關係的

如何實現單個佇列的並行消費:

jmq的實現思路:

當佇列中有10條訊息,對應的編號是0-9,當前的消費位置是5。同事來了3個請求來拉取訊息,把編號為5、6、7的訊息分別為3個消費者,每人一條。過了一段時間,3個消費成功的響應回來了,消費位置更為8.

若是6、7回來了,5響應一直回不來,5就是乙個訊息空洞。為了避免5把這個佇列卡住,先把5這個訊息,複製到乙個特殊重試佇列中,然後依然把消費位置更新為8,繼續消費。再有消費者來拉訊息,優先把重試佇列中的訊息給消費者。 

並行消費原理:

開啟並行消費後,佇列是否上鎖,由單佇列最大並行數來控制

當客戶端拉取訊息時,服務端計算此佇列上沒有ack的訊息總數,如果總數沒有超過單佇列的最大並行數,可以從後續位置積蓄拉取訊息。

訊息佇列高手課 筆記8

閘道器如何接收服務端的秒殺結果?public class requesthandler 查詢秒殺結果 result result results.remove uuid 檢查秒殺結果並返回響應 if null result result.success catch throwable ignored...

訊息佇列高手課 筆記1

哪些人適合學訊息佇列?後端開發者 訊息佇列幾乎是每個後端程式設計師都會用到的中介軟體,無論你是開發微服務,實時計算,還是機器學習程式,都需要解決程序間通訊的問題。渴望技術提公升的開發者 訊息佇列所涉及的高效能通訊 海量資料儲存 高併發這些底層的技術比較全面,並且功能簡潔 結構清晰,容易入門但又同時具...

訊息佇列 概念篇

寫在前面 在專案中總是用到的乙個中介軟體就是訊息佇列,從以前的redis到後來用到的rabbitmq,再到即將要研究的kafka,一直只知道用,卻沒有進行好好總結。正如有句話說的,你知道的越多,你不知道也就越多。以下文章是對過去的總結,以及對未來的展望。缺點2.通訊模式 訊息是指在應用間傳送的資料,...