丨消息模型主題和隊列有什么區(qū)別

現(xiàn)代的消息隊列呈現(xiàn)出的模式，一樣是經(jīng)過之前的十幾年逐步演進而來的。Qe種數(shù)據(jù)結(jié)構(gòu)，有完整而嚴(yán)格的定義。在百科中，隊列的定義是這樣的：隊列是先進先出（FIFO,First-In-First-Out）的線性表（LinearList）。在具體應(yīng)用中通常用鏈表或者數(shù)組來實現(xiàn)。隊列只允許在后端（稱為rear）進行插入操作，端（稱為front）進行刪除操作。嚴(yán)格有序早期的消息隊列，就是按照“隊列”的數(shù)據(jù)結(jié)構(gòu)來設(shè)計的。我們一起看下這個圖Produr）發(fā)消息就是入隊操作，消費者Consumr這就是最初的一種消息模型：隊列模型產(chǎn)者生產(chǎn)的所有消息的合集。消息的順序就是這些生產(chǎn)者發(fā)送消息的自然順序。如果有多如果需要將一份消息數(shù)據(jù)分發(fā)給多個消費者，要求每個消費者都能收到全量的消息，例如，對于一份訂單數(shù)據(jù)，風(fēng)控系統(tǒng)、分析系統(tǒng)、支付系統(tǒng)等都需要接收消息。這個時候，單個隊列就滿足不了需求，一個可行的解決方式是，為每個消費者創(chuàng)建一個單獨的隊列，讓生產(chǎn)者發(fā)送多份。顯然這是個比較蠢的做法，同樣的一份消息數(shù)據(jù)被到多個隊列中會浪費資源，更重要的是，生產(chǎn)者必須知道有多少個消費者。為每個消費者單獨發(fā)送一份消息，這實際上違背了消為了解決這個問題，演化出了另外一種消息模型：“發(fā)布-訂閱模型SubscribePattern）”在發(fā)布-訂閱模型中，消息的發(fā)送方稱為發(fā)布者（Publisher），消息的接收方稱為訂閱（Subscriber），服務(wù)端存放消息的容器稱為（Topic）。發(fā)布者將消息發(fā)送訂閱接收之前閱在這是一作，還可以認(rèn)為是在消費時的一個邏輯副本，每份訂閱中，訂閱者都可以接收到的所有消在消息領(lǐng)域的歷史上很長的一段時間，隊列模式和發(fā)布-訂閱模式是并存的，有些消息隊列同時支持這兩種消息模型，比如Act。我們仔細(xì)對比一下這兩種模型，生產(chǎn)者就是發(fā)布者，消費者就是訂閱者，隊列就是，并沒有本質(zhì)的區(qū)別。就是，一份消息數(shù)據(jù)能不能被消費多次的問題。實際上，在這種閱模型中，如果只有一個訂閱者，那它和隊列模型就基本是一樣的了。也就是說，發(fā)布-訂閱模型在功能層面上是可以兼容隊列模型的。現(xiàn)代的消息隊列產(chǎn)品使用的消息模型大多是這種發(fā)布-訂閱模型，當(dāng)然也有例外RabbitMQ這個例外就是RabbQ，它是少數(shù)依然堅持使用隊列模型的產(chǎn)品之一。那它是怎么解決多個消費者的問題呢？你還記得我在上節(jié)課中講到RabbitMQxchange嗎？在RabbQ中，xchae位于生產(chǎn)者和隊列之間，生產(chǎn)者并不關(guān)心將消息發(fā)送給哪個隊列，而是將消息發(fā)送給xchang由Exe同一份消息如果需要被多個消費者來消費，需要配置Exe-RabbitMQ，其中一個章專門是講如何實現(xiàn)發(fā)布訂閱的MQ講完了RabbitMQ的消息模型，我們再來看看 MQ使用的消息模型是標(biāo)準(zhǔn)的發(fā)布-訂閱模型，在 MQ的術(shù)語表中，生產(chǎn)者、消費者和與我在上面講的發(fā)布-訂閱模型中的概念是完全一樣的。 MQ也有隊列（Queue）這個概念，并且隊列在 MQ中是一個非 MQ中的作用是什么呢？這就要從消息隊列的消費機制說-Brok服務(wù)端在收到消息并將消息寫入或者隊列中后，會給生產(chǎn)者發(fā)送確認(rèn)的響應(yīng)。如果生產(chǎn)者沒有收到服務(wù)端的確認(rèn)或者收到失敗的響應(yīng)，則會重新發(fā)送消息；在消費端，消費者在收到消息并完成自己的消費業(yè)務(wù)邏輯（比如，將數(shù)據(jù)保存到數(shù)據(jù)庫中）務(wù)端發(fā)送消費成功的確認(rèn)，服務(wù)端只有收到消費確認(rèn)后，才認(rèn)為一條消息被成功消費，否則它會給消費者重新發(fā)送這條消息，直到收到對應(yīng)的消費成功確認(rèn)。這個確認(rèn)機制很好地保證了消息傳遞過程中的可靠性，但是，引入這個機制在消費端帶來了一個不小的問題。什么問題呢？為了確保消息的有序性，在某一條消息被成功消費之前，下一條消息是不能被消費的，否則就會出現(xiàn)消息空洞，違背了有序性這個原則。 MQ在主每個包含多個隊列，通過多個隊列來實現(xiàn)多實例并行生產(chǎn)和消費。需要注意的是RockeMQ只在隊列上保證消息的有序性，層面是無法保證消息的嚴(yán)格順序的MQ中，訂閱者的概念是通過消費組（ConsumrGroup）來體現(xiàn)的。每個消費組都消費中一份完整的消息，不同消費組之間消費進度彼此不受影響，也就是說，一條消ConsumrGroup1ConsumrGroup2Consum1消費了，那同組的其他消費者就不會再收到這條消息。在Topic的消費過程中，由于消息需要被不同的組進行多次消費，所以消費完的消息并不 MQ為每個消費組在每個隊列上一個消費位置ConsumrOffsetMQ的消息模型中，比較關(guān)鍵的概念就是這些了。為了便于你理解，我畫了下面張圖你可以對照這張圖再把我剛剛講的這些概念繼續(xù)消化一下，加Kafka我們再來看看另一種常見的消息隊列Kafka，Kafka的消息模型和 MQ是完全一樣 MQ中對應(yīng)的概念，和生產(chǎn)消費過程中的確認(rèn)機制，都完全適用于Kafka。唯一的區(qū)別是，在Kafka中，隊列這個概念的名稱不一樣，Kafka中對應(yīng)的來總下本學(xué)習(xí)容。我們隊列和的，這概念后實際上對應(yīng)著兩種不同的消息模型：隊列模型和發(fā)布-常用的消息隊列中，RabbitMQ采用的是隊列模型，但是它一樣可以實現(xiàn)發(fā)布-訂閱的功能 MQ和Kafka采用的是發(fā)布-訂閱模型，并且二者的消息模型是基本一致的型有助于你用最佳的去使用消息隊列。但業(yè)務(wù)模型不等于就是實現(xiàn)層面的模型。比如說MySQL和Hbase同樣是支持SQL的數(shù)據(jù)庫，它們的業(yè)務(wù)模型中，存放數(shù)據(jù)的單元都是“表”，但是在實現(xiàn)層面，沒有哪個數(shù)據(jù)是以二維表的方式去數(shù)據(jù)的，MySQL使用B+樹來數(shù)據(jù)，而HBase使用的是KV的結(jié)構(gòu)來。同樣，像Kafka和 MQ的業(yè)務(wù)模型基本是一樣的，并不是說他們的最后給大家留一個思考題。剛剛我在介紹 Q的消息模型時講過，在消費的為了保證消息的不丟失和嚴(yán)格順序，每個隊列只能串行消費，無法做到并發(fā)，否則會出現(xiàn)消費空洞的問題。那如果放寬一下限制，不要求嚴(yán)格順序，能否做到單個隊列的并行消費呢？如果可以，該如何實現(xiàn)？歡迎在留言區(qū)與我討論。感謝閱讀，如果你覺得這篇文章對你有一些啟發(fā)，也歡迎把它給你的朋友?歸科技所有，不得售賣。頁面已增加防盜追蹤，將依法其上一 02|該如何選擇消息隊列言精選留言言發(fā)條橙子。mq更新（）消息（比如下架），那商品中心有多臺機器就對應(yīng)多個producer。消費者組有兩個，分別是導(dǎo)購中心和活動中心。…展作者回復(fù):A1：不是，消費者組和隊列數(shù)沒有關(guān)系，你這個例子中消費者組的數(shù)量是2個。隊列數(shù) 2 4展9沒啥問題，就是想點個贊，老 很展4 展3 作者回復(fù):對應(yīng) 1 3 展2老師您好，關(guān) mq的那有幾個疑問sumergoup中的某個sumer是和某個具體的queuesumer每次都隨機從某queu消費，另外如果是一一關(guān)聯(lián)的話，那某個ser掛了，那關(guān)聯(lián)的那個queue的消息該由哪個sumer來消費呢？展同一個consumergroup中最多只能有一個consumer占用。1 2展作者回復(fù):沒錯！具體可以看一