分散式訊息佇列 RocketMQ 原始碼分析 —— Message 順序傳送與消費
本文主要基於 RocketMQ 4.0.x 正式版
1. 概述
建議前置閱讀內容:
當然對 Message
傳送與消費已經有一定了解的同學,可以選擇跳過。
RocketMQ
提供了兩種順序級別:
- 普通順序訊息 :
Producer
將相關聯的訊息傳送到相同的訊息佇列。 - 完全嚴格順序 :在
普通順序訊息
的基礎上,Consumer
嚴格順序消費。
絕大部分場景下只需要用到普通順序訊息。
例如說:給使用者傳送簡訊訊息 + 傳送推送訊息,將兩條訊息傳送到不同的訊息佇列,若其中一條訊息佇列消費較慢造成堵塞,使用者可能會收到兩條訊息會存在一定的時間差,帶來的體驗會相對較差。當然類似這種場景,即使有一定的時間差,不會產生系統邏輯上BUG
普通順序訊息
效能能更加好。那麼什麼時候使用使用完全嚴格順序?如下是來自官方文件的說明:
目前已知的應用只有資料庫
binlog
同步強依賴嚴格順序訊息,其他應用絕大部分都可以容忍短暫亂序,推薦使用普通的順序訊息
相關推薦
分散式訊息佇列 RocketMQ 原始碼分析 —— Message 順序傳送與消費
本文主要基於 RocketMQ 4.0.x 正式版 1. 概述 建議前置閱讀內容: 當然對 Message 傳送與消費已經有一定了解的同學,可以選擇跳過。 RocketMQ 提供了兩種順序級別: 普通順序訊息 :Producer 將相關聯的訊息傳送到相同
分散式訊息佇列RocketMQ原始碼分析之2 -- Broker與NameServer心跳機制
我們知道,Kafka是通過ZK的臨時節點來監測Broker的死亡的。當一個Broker掛了之後,ZK上面對應的臨時節點被刪除,同時其他Broker收到通知。 那麼在RocketMQ中,對應的NameServer是如何判斷一個Broker的死亡呢? 有興趣朋友
分散式訊息佇列RocketMQ原始碼分析之3 -- Consumer負載均衡機制 -- Rebalance
同Kafka一樣,RocketMQ也需要探討一個問題:如何把一個topic的多個queue分攤給不同的consumer,也就是負載均衡問題。 有興趣朋友可以關注公眾號“架構之道與術”, 獲取最新文章。 或掃描如下二維碼: 在討論這個問題之前,我們先看一
分散式訊息佇列 RocketMQ原始碼解析:事務訊息
摘要: 原創出處 http://www.iocoder.cn/RocketMQ/message-
分散式訊息佇列RocketMQ&Kafka -- 訊息的“順序消費”-- 一個看似簡單的複雜問題
在說到訊息中介軟體的時候,我們通常都會談到一個特性:訊息的順序消費問題。這個問題看起來很簡單:Producer傳送訊息1, 2, 3。。。 Consumer按1, 2, 3。。。順序消費。 但實際情況卻是:無論RocketMQ,還是Kafka,預設都不保證訊息
分散式訊息佇列RocketMQ--事務訊息--解決分散式事務
說到分散式事務,就會談到那個經典的”賬號轉賬”問題:2個賬號,分佈處於2個不同的DB,或者說2個不同的子系統裡面,A要扣錢,B要加錢,如何保證原子性? 一般的思路都是通過訊息中介軟體來實現“最終一致性”:A系統扣錢,然後發條訊息給中介軟體,B系統接收此訊息,進行加錢。 但這裡面有個問題:A是先update D
RocketMQ原始碼分析之順序消費
概述 RocketMQ按照順序消費有兩種順序級別,一種是普通順序訊息。另外一種是更完全嚴格順序 普通順序訊息指的是Producer將訊息傳送到相對應的訊息佇列上面 完全嚴格順序:在普通順序訊息的基礎上,Consumer嚴格進行順序消費 在絕大部分情況下只
分散式訊息佇列RocketMQ與Kafka的18項差異之“撥亂反正”
我們知道,阿里的RocketMQ其實源自Kafka。同時網路上一直流傳著1篇阿里中介軟體團隊所寫的RocketMQ與Kafka的18項差異的文章,並且被廣泛轉發。比如: http://blog.csdn.net/damacheng/article/detail
分散式訊息佇列RocketMQ--事務訊息--解決分散式事務的最佳實踐
說到分散式事務,就會談到那個經典的”賬號轉賬”問題:2個賬號,分佈處於2個不同的DB,或者說2個不同的子系統裡面,A要扣錢,B要加錢,如何保證原子性? 一般的思路都是通過訊息中介軟體來實現“最終一致性”:A系統扣錢,然後發條訊息給中介軟體,B系統接收此訊息,進行加錢。
dubbo原始碼分析22 -- consumer 傳送與接收原理
在前面的文章中,我們分析了 dubbo 從 provider 進行服務暴露,然後把服務資訊註冊到註冊中心上面解耦 consumer 與 provider 的呼叫。consumer 通過 javassist 建立代理物件引用遠端服務。當通過代理物件呼叫遠端服務的時候,講到進行真
RabbitMQ系列之七 分散式訊息佇列應用場景之非同步處理、應用解耦、流量削鋒和訊息通訊理解分析
摘要:訊息佇列中介軟體是分散式系統中重要的元件,主要解決應用耦合,非同步訊息,流量削鋒等問題。實現高效能,高可用,可伸縮和最終一致性架構。是大型分散式系統不可缺少的中介軟體。 目前在生產環境,使用較多的訊息佇列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,
RocketMQ 原始碼分析 訊息儲存(預備知識二)(轉載+整理)
前言 在RMQ中為了提高commitlog檔案的讀寫效率,而採用了一個叫做記憶體對映的技術。按照我的理解,記憶體對映在處理大檔案上有非常大的效能提升,所以這篇來記錄一下我對記憶體對映的理解。 使用者態和核心態 我們都知道作業系統分為使用者態和核心態,核心態表示當前為核心程式
RocketMQ 原始碼分析 訊息儲存(預備知識一)
前言 看到RocketMQ的效能問題的時候,通常能看到page cache、順序IO寫、預讀等,要想設計出一個高效能的中介軟體,這部分的知識是絕對要掌握的。 順序IO讀寫為什麼速度更快 當需要從硬碟上讀取一個檔案時,首先會要求磁頭定位到這個檔案的起始扇區。這個定位過程包
RocketMQ原始碼分析之RocketMQ事務訊息實現原理上篇(二階段提交)
根據上文的描述,傳送事務訊息的入口為: TransactionMQProducer#sendMessageInTransaction: public TransactionSendResult sendMessageInTransaction(final Message msg, final Object
RocketMQ原始碼分析之從官方示例窺探:RocketMQ事務訊息實現基本思想
RocketMQ4.3.0版本開始支援事務訊息,後續分享將開始將剖析事務訊息的實現原理。首先從官方給出的Demo例項入手,以此通往RocketMQ事務訊息的世界中。 官方版本未釋出之前,從apache rocketmq第一個版本上線後,程式碼中存在與事務訊息相關的程式碼,例如COMMIT、ROLLBACK、
分散式訊息佇列(Message Queue)系統:kafka掃盲
分散式系統很重要的一個設計原則是鬆耦合,即儘量減少子系統間的依賴。這樣各個子系統可以相互獨立的進行演進,維護,重用等。Message Queue (MQ)是一種很好的解耦手段。要了解MQ在系統整合中的作用,可以看Enterprise Integration Pattern
RTMPdump(libRTMP) 原始碼分析 8: 傳送訊息(Message)
=====================================================RTMPdump(libRTMP) 原始碼分析系列文章:=====================================================函式呼叫
RocketMQ原始碼分析----傳送訊息
獲取到了TopicPublishInfo資訊之後,需要選擇一個佇列進行傳送,selectOneMessageQueue方法其主要的處理步驟如下: 1.獲取index值(儲存在ThreadLocal中,為一個隨機的int,每次執行緒取到會+1) 2.如果lastBrokerName為空:將index和佇列數量
RocketMQ中PullConsumer的訊息拉取原始碼分析
在PullConsumer中,有關訊息的拉取RocketMQ提供了很多API,但總的來說分為兩種,同步訊息拉取和非同步訊息拉取 同步訊息拉取以同步方式拉取訊息都是通過DefaultMQPullConsumerImpl的pullSyncImpl方法: 1 private PullResult pull
【RocketMQ原始碼分析】深入訊息儲存(1)
![](https://antzyun.oss-cn-beijing.aliyuncs.com/img204d5b68da5e7e26d371c966fbf81d8.jpg) 最近在學習RocketMQ相關的東西,在學習之餘沉澱幾篇筆記。 RocketMQ有很多值得關注的設計點,訊息傳送、訊息消費、路由中