成人国产在线小视频_日韩寡妇人妻调教在线播放_色成人www永久在线观看_2018国产精品久久_亚洲欧美高清在线30p_亚洲少妇综合一区_黄色在线播放国产_亚洲另类技巧小说校园_国产主播xx日韩_a级毛片在线免费

資訊專欄INFORMATION COLUMN

如何解決MQ消息消費(fèi)順序問題

Atom / 1320人閱讀

摘要：利用的高級特性特性是一種負(fù)載均衡的機(jī)制。在一個(gè)消息被分發(fā)到之前，首先檢查消息屬性。屬性為某個(gè)值的消息單個(gè)消息或消息集合在描述，和的對應(yīng)關(guān)系，以及負(fù)載均衡策略時(shí)。同樣做到了保證消息的順序情況下，均衡消費(fèi)的消費(fèi)消息。

通常mq可以保證先到隊(duì)列的消息按照順序分發(fā)給消費(fèi)者消費(fèi)來保證順序，但是一個(gè)隊(duì)列有多個(gè)消費(fèi)者消費(fèi)的時(shí)候，那將失去這個(gè)保證，因?yàn)檫@些消息被多個(gè)線程并發(fā)的消費(fèi)。但是有的時(shí)候消息按照順序處理是很重要的，那我們該如何來保證消息的順序呢，下面將從activemq和rocketmq來看看，它們是如何來保證消息的順序問題的？我們還可以有別的處理方案么？

Activemq處理方案

1、利用Activemq的高級特性：consumer之獨(dú)有消費(fèi)者（exclusive consumer）

在ActiveMQ4.x中可以采用Exclusive Consumer，broker會(huì)從queue中，一次發(fā)送消息給一個(gè)消費(fèi)者，這樣就避免了多個(gè)消費(fèi)者并發(fā)消費(fèi)的問題，從而保證順序，配置如下：

queue = new ActiveMQQueue("TEST.QUEUE?consumer.exclusive=true");
consumer = session.createConsumer(queue);

當(dāng)在接收信息的時(shí)候有一個(gè)或者多個(gè)備份接收消息者和一個(gè)獨(dú)占消息者的同時(shí)接收時(shí)候，無論兩者創(chuàng)建先后，在接收的時(shí)候，均為獨(dú)占消息者接收。

當(dāng)在接收信息的時(shí)候，有多個(gè)獨(dú)占消費(fèi)者的時(shí)候，只有一個(gè)獨(dú)占消費(fèi)者可以接收到消息。

當(dāng)有多個(gè)備份消息者和多個(gè)獨(dú)占消費(fèi)者的時(shí)候，當(dāng)所有的獨(dú)占消費(fèi)者均close的時(shí)候，只有一個(gè)備份消費(fèi)者接到到消息。

當(dāng)主消費(fèi)者掛了話，會(huì)立刻啟用故障切換轉(zhuǎn)移到下一臺(tái)消費(fèi)者繼續(xù)消費(fèi)

                                   圖1

獨(dú)占消息就是在有多個(gè)消費(fèi)者同時(shí)消費(fèi)一個(gè)queue時(shí)，可以保證只有一個(gè)消費(fèi)者可以消費(fèi)消息，這樣雖然保證了消息的順序問題，不過也帶來了一個(gè)問題，就是這個(gè)queue的所有消息將只會(huì)在這一個(gè)主消費(fèi)者上消費(fèi)，其他消費(fèi)者將閑置，達(dá)不到負(fù)載均衡分配，而實(shí)際業(yè)務(wù)我們可能更多的是這樣的場景，比如一個(gè)訂單會(huì)發(fā)出一組順序消息，我們只要求這一組消息是順序消費(fèi)的，而訂單與訂單之間又是可以并行消費(fèi)的，不需要順序，因?yàn)轫樞蛞矝]有任何意義，有沒有辦法做到呢？答案是可以的，下面就來看看activemq的另一個(gè)高級特性之messageGroup。

2、利用Activemq的高級特性：messageGroups

Message Groups特性是一種負(fù)載均衡的機(jī)制。在一個(gè)消息被分發(fā)到consumer之前，broker首先檢查消息JMSXGroupID屬性。如果存在，那么broker會(huì)檢查是否有某個(gè)consumer擁有這個(gè)message group。如果沒有，那么broker會(huì)選擇一個(gè)consumer，并將它關(guān)聯(lián)到這個(gè)message group。此后，這個(gè)consumer會(huì)接收這個(gè)message group的所有消息，直到：

Consumer被關(guān)閉

Message group被關(guān)閉，通過發(fā)送一個(gè)消息，并設(shè)置這個(gè)消息的JMSXGroupSeq為-1

                                   圖2

配置如下：

bytesMessage.setStringProperty("JMSXGroupID", "constact-20100000002");
bytesMessage.setIntProperty("JMSXGroupSeq", -1);

如上圖所示，同一個(gè)queue中，擁有相同JMSXGroupID的消息將發(fā)往同一個(gè)消費(fèi)者，解決順序問題，不同分組的消息又能被其他消費(fèi)者并行消費(fèi)，解決負(fù)載均衡的問題，兩全其美啦！

問題討論，除了上述Activemq為我們提供的方案，我們是否不依賴這兩種特性，也能解決順序問題呢？

Rocketmq處理方案

那rocketmq又是如何保證消息順序消費(fèi)的問題呢？

Rocketmq跟傳統(tǒng)的MQ有一點(diǎn)區(qū)別，這里有必要講一下topic的概念，Topic是RocketMQ中的一個(gè)重要概念，RocketMQ的各組件都是圍繞著Topic建立起對應(yīng)關(guān)系的，在RocketMQ官方文檔和本文中， Topic在不同的語境下被賦予了兩種不同的語義：

1)消息的Topic屬性值：在描述Consumer的訂閱設(shè)置信息或消息的屬性時(shí)。

2)Topic屬性為某個(gè)值的消息(單個(gè)消息或消息集合)：在描述Broker，Producer和Consumer的對應(yīng)關(guān)系，Queue以及負(fù)載均衡策略時(shí)。

topic和queue的對應(yīng)關(guān)系是一個(gè)topic擁有多個(gè)queue，當(dāng)producer往broken發(fā)送消息時(shí)，消息會(huì)存儲(chǔ)在topic下的不同隊(duì)列中，而一個(gè)隊(duì)列只會(huì)被一個(gè)consumer消費(fèi)，這樣消息戶被均衡負(fù)載到不同的隊(duì)列下，也就是會(huì)被多個(gè)消費(fèi)者并行消費(fèi)，順序就無法保證了。該怎么辦呢？答案是把需要順序消費(fèi)的消息發(fā)送到同一臺(tái)broker server下的同一個(gè)隊(duì)列，而這些消息也只會(huì)被同一個(gè)消費(fèi)者消費(fèi)，這樣就可以保證嚴(yán)格的順序了，如下圖：

1、消息要有順序，首先得保證producer發(fā)送消息有順序，如上圖msg1，msg2，msg3發(fā)送到queue0是要有順序的，只要producer等待前面的消息發(fā)送成功，在發(fā)送后面的消息就完全可以保證了，

2、假設(shè)msg1發(fā)送給consumer1，消費(fèi)沒有響應(yīng)，該怎么辦呢？是繼續(xù)發(fā)送msg2還是重新發(fā)送msg1，一般為了保證消息一定被消費(fèi)，肯定會(huì)選擇重發(fā)msg1到下一臺(tái)消費(fèi)者consumer2。

3、消費(fèi)端1沒有響應(yīng)Server時(shí)有兩種情況，一種是msg1確實(shí)沒有到達(dá)(數(shù)據(jù)在網(wǎng)絡(luò)傳送中丟失)，另外一種消費(fèi)端已經(jīng)消費(fèi)msg2且已經(jīng)發(fā)送響應(yīng)消息，只是MQ Server端沒有收到。如果是第二種情況，重發(fā)msg1，就會(huì)造成msg1被重復(fù)消費(fèi)。也就引入了消息重復(fù)問題，那就要冪等了。

Rocketmq同樣做到了保證消息的順序情況下，均衡消費(fèi)的消費(fèi)消息。

綜上，我看到，在分布式系統(tǒng)中，要想消息有順序的被消費(fèi)，無論是Activemq還是Rocketmq都要想辦法讓有順序的消息被同一消費(fèi)者消費(fèi)，而不是并發(fā)的消費(fèi)，在消費(fèi)者消費(fèi)成功后，接著才會(huì)消費(fèi)下一個(gè)消息，這樣就可以保證了嚴(yán)格的順序。

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/69153.html

相關(guān)文章

  • 關(guān)于MQ的幾件小事（六）消息積壓在消息隊(duì)列里怎么辦

    摘要：緊接著征用倍的機(jī)器來部署，每一批消費(fèi)一個(gè)臨時(shí)的消息。這種做法相當(dāng)于臨時(shí)將資源和資源擴(kuò)大倍，以正常速度的倍來消費(fèi)消息。解決方案這種情況下，實(shí)際上沒有什么消息擠壓，而是丟了大量的消息。 1.大量消息在mq里積壓了幾個(gè)小時(shí)了還沒解決 場景： 幾千萬條數(shù)據(jù)在MQ里積壓了七八個(gè)小時(shí)，從下午4點(diǎn)多，積壓到了晚上很晚，10點(diǎn)多，11點(diǎn)多。線上故障了，這個(gè)時(shí)候要不然就是修復(fù)consumer的問題，讓他恢復(fù)消...

    SwordFly 評論0 收藏0

  • 關(guān)于MQ的幾件小事（五）如何保證消息按順序執(zhí)行

    摘要：一個(gè)對應(yīng)一個(gè)，但是里面進(jìn)行了多線程消費(fèi)，這樣也會(huì)造成消息消費(fèi)順序錯(cuò)誤。保證消息的消費(fèi)順序拆分多個(gè)，每個(gè)一個(gè)，就是多一些而已，確實(shí)是麻煩點(diǎn)這樣也會(huì)造成吞吐量下降，可以在消費(fèi)者內(nèi)部采用多線程的方式取消費(fèi)。 1.為什么要保證順序 消息隊(duì)列中的若干消息如果是對同一個(gè)數(shù)據(jù)進(jìn)行操作，這些操作具有前后的關(guān)系，必須要按前后的順序執(zhí)行，否則就會(huì)造成數(shù)據(jù)異常。舉例： 比如通過mysql binlog進(jìn)行兩個(gè)數(shù)據(jù)...

    h9911 評論0 收藏0

  • 使用canal+Kafka進(jìn)行數(shù)據(jù)庫同步實(shí)踐

    摘要：比如，服務(wù)數(shù)據(jù)庫的數(shù)據(jù)來源于服務(wù)的數(shù)據(jù)庫服務(wù)的數(shù)據(jù)有變更操作時(shí)，需要同步到服務(wù)中。第二種解決方案通過數(shù)據(jù)庫的進(jìn)行同步。并且，我們還用這套架構(gòu)進(jìn)行緩存失效的同步。目前這套同步架構(gòu)正常運(yùn)行中，后續(xù)有遇到問題再繼續(xù)更新。在微服務(wù)拆分的架構(gòu)中，各服務(wù)擁有自己的數(shù)據(jù)庫，所以常常會(huì)遇到服務(wù)之間數(shù)據(jù)通信的問題。比如，B服務(wù)數(shù)據(jù)庫的數(shù)據(jù)來源于A服務(wù)的數(shù)據(jù)庫；A服務(wù)的數(shù)據(jù)有變更操作時(shí)，需要同步到B服務(wù)中。第一...

    Tecode 評論0 收藏0

  • RocketMq消息中間件介紹

    摘要：消息生產(chǎn)者，負(fù)責(zé)發(fā)消息到。消息消費(fèi)者，負(fù)責(zé)從上拉取消息進(jìn)行消費(fèi)，消費(fèi)完進(jìn)行。集群部署端完全消費(fèi)正常后在進(jìn)行手動(dòng)確認(rèn)。消息發(fā)送成功后，服務(wù)器返回確認(rèn)消息給生產(chǎn)者。根據(jù)本地事務(wù)執(zhí)行的結(jié)果向發(fā)送提交或回滾消息。 RabbitMQerlang開發(fā)，對消息堆積的支持并不好，當(dāng)大量消息積壓的時(shí)候，會(huì)導(dǎo)致RabbitMQ的性能急劇下降。...

    goji 評論0 收藏0

  • Java面試之消息隊(duì)列

    摘要：將消息持久化成功之后，向發(fā)送方確認(rèn)消息已經(jīng)發(fā)送成功，此時(shí)消息為半消息。發(fā)送方收到消息回查后，需要檢查對應(yīng)消息的本地事務(wù)執(zhí)行的最終結(jié)果。發(fā)送方根據(jù)檢查得到的本地事務(wù)的最終狀態(tài)再次提交二次確認(rèn)，仍按照步驟對半消息進(jìn)行操作。1.應(yīng)用場景 解耦 異步 流量消峰 日志記錄 2.重復(fù)消息的解決方案 消費(fèi)端處理消息的業(yè)務(wù)邏輯保持冪等性 保證每條消息都有唯一編號且保證消息處理成功與去重表的日志同時(shí)出現(xiàn)...

    番茄西紅柿 評論0 收藏0

發(fā)表評論

0條評論

最新活動(dòng)
閱讀需要支付1元查看
<