訊息模型主題和佇列有什麼區別？

可以看到，技術圈的風向一直在變，大資料、雲的熱度已經在慢慢消退，現在當紅的是 ai 和 iot。這些火熱的概念，它最終要從**和 ppt 落地，變成真正能解決問題的系統，否則就是乙個空中樓閣。那不變的是什麼？(一些題外話的感觸)

最初的訊息佇列，就是乙個嚴格意義上的佇列

如果需要將乙份訊息資料分發給多個消費者，要求每個消費者都能收到全量的訊息，例如，對於乙份訂單資料，風控系統、分析系統、支付系統等都需要接收訊息。這個時候，單個佇列就滿足不了需求，乙個可行的解決方式是，為每個消費者建立乙個單獨的佇列，讓生產者傳送多份 (不好的做法).

為了解決這個問題，演化出了另外一種訊息模型：「發布 - 訂閱模型（publish-subscribe pattern）」。

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

現代的訊息佇列產品使用的訊息模型大多是這種發布 - 訂閱模型

它是少數依然堅持使用佇列模型的產品之一.

在 rabbitmq 中，exchange 位於生產者和佇列之間，生產者並不關心將訊息傳送給哪個佇列，而是將訊息傳送給 exchange，由 exchange 上配置的策略來決定將訊息投遞到哪些佇列中。

同乙份訊息如果需要被多個消費者來消費，需要配置 exchange 將訊息傳送到多個佇列，每個佇列中都存放乙份完整的訊息資料，可以為乙個消費者提供消費服務。

這也可以變相地實現新發布 - 訂閱模型中，「乙份訊息資料可以被多個訂閱者來多次消費」這樣的功能。

rocketmq 使用的訊息模型是標準的發布 - 訂閱模型

確認機制很好地保證了訊息傳遞過程中的可靠性，但是，引入這個機制在消費端帶來了乙個不小的問題。為了確保訊息的有序性，在某一條訊息被成功消費之前，下一條訊息是不能被消費的，否則就會出現訊息空洞，違背了有序性這個原則。

也就是說，每個主題在任意時刻，至多只能有乙個消費者例項在進行消費，那就沒法通過水平擴充套件消費者的數量來提公升消費端總體的消費效能。為了解決這個問題，rocketmq 在主題下面增加了佇列的概念。

rocketmq 中，訂閱者的概念是通過消費組（consumer group）來體現的。每個消費組都消費主題中乙份完整的訊息，不同消費組之間消費進度彼此不受影響，也就是說，一條訊息被 consumer group1 消費過，也會再給 consumer group2 消費。

消費組中包含多個消費者，同乙個組內的消費者是競爭消費的關係，每個消費者負責消費組內的一部分訊息。如果一條訊息被消費者 consumer1 消費了，那同組的其他消費者就不會再收到這條訊息。

kafka 的訊息模型和 rocketmq 是完全一樣的.

唯一的區別是，在 kafka 中，佇列這個概念的名稱不一樣，kafka 中對應的名稱是分割槽（partition）

業務模型不等於就是實現層面的模型。比如說 mysql 和 hbase 同樣是支援 sql 的資料庫，它們的業務模型中，存放資料的單元都是「表」，但是在實現層面，沒有哪個資料庫是以二維表的方式去儲存資料的，mysql 使用 b+ 樹來儲存資料，而 hbase 使用的是 kv 的結構來儲存。同樣，像 kafka 和 rocketmq 的業務模型基本是一樣的，並不是說他們的實現就是一樣的，實際上這兩個訊息佇列的實現是完全不同的。

訊息模型主題和佇列有什麼區別？

訊息佇列 03 訊息模型主題和佇列有什麼區別

訊息佇列策略訊息模型主題和佇列有什麼區別？

訊息佇列有什麼優缺點？

訊息模型 主題和佇列有什麼區別？

訊息佇列 03 訊息模型 主題和佇列有什麼區別

訊息佇列 策略 訊息模型 主題和佇列有什麼區別？

訊息佇列有什麼優缺點？

相關推薦

訊息模型主題和佇列有什麼區別？

訊息佇列 03 訊息模型主題和佇列有什麼區別

訊息佇列策略訊息模型主題和佇列有什麼區別？