2. 程式人生 > >1.偏頭痛楊的rocketmq4.x入門之基礎概念掃盲篇

1.偏頭痛楊的rocketmq4.x入門之基礎概念掃盲篇

阿新 • • 發佈：2019-01-28
前戲閱讀本文之前，讀者必須自己清楚什麼是訊息佇列，以及訊息佇列的一些基本概念，例如：訊息、生產者、消費者等。我們如果需要玩非同步、分散式事務、程式碼物理解耦、削峰平谷、釋出訂閱等等，可以使用訊息佇列中介軟體，那麼阿里的rocketmq是一款比較中意的產品，既有開源版又有商業版（阿里雲的mq有點貴，誰用誰知道）。商業版與開源版的api不同，有的概念也不同。。。rocketmq的特點是純java編寫、高效能、高吞吐、分散式等等。目前捐贈給阿帕奇，正在被孵化中，有望成為國內的頂級阿帕奇專案之一，希望大家能支援國貨。rocketmq裡的概念比較多，坑也不少，有興趣的童鞋可以研究一下他的原始碼，都是java寫的。
一些大廠面試題也會問到。想要完全掌握這些理論還是需要系統學習的。專案的git站點：rocketmq的歷程：metaq1.x->metaq2.x->alibaba-rocketmq3.x->apache-rocketmq4.x
阿里雲商業版訊息佇列的優缺點：優點：1.省事，傻瓜式運維。2.省心，幾乎不出問題。缺點：1.如果業務量較小，那麼成本比較貴。2.訊息佇列伺服器時間不可控，會導致生產者&消費者伺服器與訊息佇列伺服器的時間不同，造成隱患。 感謝蠢新給予我的幫助與支援，在我最迷茫的時候（被rocketmq的坑卡住的時候）給我方向，非常感謝你。RocketMQ的特點
  • 支援嚴格的訊息順序
  • 億級訊息堆積能力（不考慮記憶體&磁碟等資源）
  • 提供配置、指標和監控等功能豐富Dashboard
  • 消費者同時支援Push與Pull方式消費訊息
  • 歷經多次天貓雙十一海量訊息考驗
  • 訊息失敗重試機制
  • 訊息事務機制
  • producer、consumer、broker、nameserver都可以玩分散式，叢集部署，消除單點故障。
rocketmq的四大金剛（核心組成部分）producer、consumer在客戶端，nameserver、broker在服務端。
  • producer
訊息的生產者，負責傳送訊息，將訊息推送給broker。一般由業務系統負責產生訊息。訊息有3種傳送方式：同步、非同步、單向。 
  • broker
rocketmq的核心元件，負責訊息的接收、儲存（持久化到磁碟）、被消費者拉取訊息等功能。
broker也儲存訊息相關的元資料，包括：消費者組、消費進度、topic&queue資訊等。broker是個邏輯概念，1個broker = 1個master + 0至n個slave，具有同1個broker name的master和slave進行配對。
  • consumer
訊息的消費者，從broker上拉取訊息從而進行消費。rocketmq提供兩種消費者。一般是後臺系統負責非同步消費訊息。主動消費者：DefaultMQPullConsumer，從broker中拉取一批訊息並消費，主動權由消費者控制。被動消費者：DefaultMQPushConsumer，消費者實現回撥介面，一旦有訊息，broker回撥介面，消費者被動響應。（被動消費者給使用者感覺是訊息從broker推到了應用客戶端，但是實際PushConsumer內部是使用長輪詢Pull方式從broker拉訊息，然後再回呼叫戶Listener方法。）
  • name server
註冊中心的作用，提供輕量級的服務發現和提供路由資訊（broker的服務註冊與發現）。nameserver存有全量的路由資訊，提供對等的讀寫服務，支援快速擴縮容。nameserver接收broker的請求，註冊broker的路由資訊。nameserver接收client（producer/consumer）的請求，根據訊息的topic獲取相應的broker路由資訊。（手動建立的topic可以指定broker，自動建立的topic會隨機指定broker，也許指定單個或全部，topic的概念在後面。）叢集部署後，節點之間無任何資訊同步。（在1.x與2.x時代是使用zookeeper，3.x時代自主研發了nameserver，更加輕量級，效能更好）其他核心概念
  • topic（主題）
一種訊息的邏輯分類（訊息的型別），比如說你有訂單類的訊息，也有庫存類的訊息，那麼就需要進行分類儲存。生產者方面：發訊息時需指定topic，可以有1-n個生產者釋出1個topic的訊息，也1個生產者可以釋出不同topic的訊息。消費者方面：收訊息時需訂閱topic，可以有1-n個消費者組訂閱1個topic的訊息，1個消費者組可以訂閱不同topic的訊息。1個訊息必須指定1個topic，topic允許自動建立與手工建立，topic建立時需要指定broker，可以指定1個或多個，name server就是通過broker與topic的對映關係來做路由。producer和consumer在生產和消費訊息時，都需要指定訊息的 topic，當topic匹配時，consumer 才會消費到producer傳送的訊息。topic與broker是多對多的關係，一個topic分佈在多個broker上，一個broker可以配置多個topic。
  • message（訊息）
message是訊息的載體。每個message必須指定一個topic，相當於寄信的地址。message還有一個可選的tag設定，以便消費端可以基於tag進行過濾訊息。message還有擴充套件的kv結構，例如你可以設定一個業務key到你的訊息中，在broker上查詢訊息並診斷問題。注意：msgId與msgKey。
  • tag（標籤）
標籤可以被認為是對topic的進一步細化。一般在相同業務模組中通過引入標籤來標記不同用途的訊息。區分相同topic下不同種類的訊息。生產到哪個topic的哪個tag下，消費者也是從topic的哪個tag進行消費，即實現訊息的過濾。
  • queue（佇列）
queue是訊息的物理管理單位，而topic是邏輯管理單位。一個topic下可以有多個queue，預設自動建立是4個，手動建立是8個。queue的引入使得訊息儲存可以分散式叢集化，具有了水平擴充套件的能力。1個message只能屬於1個queue、1個topic。在rocketmq中，所有訊息佇列都是持久化，長度無限的資料結構，所謂長度無限是指佇列中的每個儲存單元都是定長，訪問其中的儲存單元使用offset來訪問，offset 為 java long 型別，64 位，理論上在 100年內不會溢位，所以認為是長度無限，另外佇列中只儲存最近幾天的資料，之前的資料會按照過期時間來刪除。也可以認為 Message Queue是一個長度無限的陣列，offset就是下標。rocketmq中，producer將訊息傳送給broker時，需要指定傳送到哪一個queue中，預設情況下，producer會輪詢的將訊息傳送到每個queue中，順序是隨機的，但總體上每個queue的訊息數量均分，所有broker下的queue合併成一個list去輪詢，也可以由程式設計師通過MessageQueueSelector介面來指定具體傳送到哪個queue中。對於consumer而言，會為每個consumer分配固定的佇列（如果佇列總數沒有發生變化），consumer從固定的佇列中去拉取沒有消費的訊息進行處理。消費端會通過RebalanceService執行緒，10秒鐘做一次基於topic下的所有佇列負載，獲取同一個Consumer Group下的所有Consumer例項數或Topic的queue的個數是否改變，通知所有Consumer例項重新做一次負載均衡演算法。
  • offset（消費進度）
理解成消費進度，可自增。
  • commit log（儲存檔案）
雖然每個topic下面有很多message queue，但是message queue本身並不儲存訊息。真正的訊息儲存會寫在CommitLog的檔案，message queue只是儲存CommitLog中對應的位置資訊，方便通過message queue找到對應儲存在CommitLog的訊息。 不同的topic，message queue都是寫到相同的CommitLog 檔案，也就是說CommitLog完全的順序寫。四大金剛的呼叫關係
服務啟動順序：name server->broker->producer&consumer每個broker與name server叢集中的所有節點建立長連線，定時註冊topic&broker的路由資訊到所有name server中。producer與name server叢集中的其中一個節點（隨機選擇）建立長連線，定期從name server獲取topic路由資訊，並向提供topic服務的broker master建立長連線，且定期向broker master傳送心跳，produce無狀態，可叢集部署。producer只能將訊息傳送到broker master，但是consumer則不一樣。consumer與name server叢集中的其中一個節點（隨機選擇）建立長連線，定期從name server獲取topic路由資訊，consumer同時與提供topic服務的master和slave建立長連線且定時傳送心跳，consumer既可以從broker master訂閱訊息，也可以從broker slave訂閱訊息，訂閱規則由broker配置決定。broker一旦需要橫向擴充套件，只需要啟動更多的broker即可，然後把對應的topic建上，客戶端的queue集合即會變大，並且由於每個group下面的topic的配置都是獨立的，也就說可以讓broker1下面的那個topic的queue數量是4，其他broker下的topic queue數量是2，這樣broker1則得到更大的負載。

rocketmq的組
相同組的例項組成了一個叢集，具有天然的訊息負載均衡及高效的水平擴充套件機制。例如：生產者生產了9條訊息，消費者組有3個消費者例項，那麼每個例項將均攤3條訊息！
  • ConsumerGroup（訂閱組）
具有同樣邏輯消費同樣訊息的consumer，可以歸併為一個group。同一個group內的消費者，可以共同消費（叢集消費模式）對應topic的訊息，達到分散式並行處理（負載均衡）的功能。在叢集模式下，同一條訊息只會被同一個 consumer group 中的一個消費者消費，不同 consumer group 的 consumer 可以消費同一條訊息；而廣播模式則是多個 consumer 都會消費到同一條訊息。broker建立ConsumerGroup，ConsumerGroup內的Consumer例項控制Topic的訂閱，ConsumerGroup內的Consumer例項可以訂閱多個Topic。
  • ProducerGroup（生產組）
通常具有同樣作用（同樣topic）的一些producer可以歸為同一個group。在事務訊息機制中，如果傳送某條事務訊息後的producer-A宕機，使得事務訊息一直處於PREPARED狀態並超時，則broker會回查同一個group的其他producer，確認這條訊息應該commit還是rollback。
訊息佇列產品對比rocketmq>kafka>activemq，整體上rocketmq還是佔優勢的。
總結主要掌握rocketmq的四大金剛以及互相的關係，此外一些核心概念例如：topic、queue、message也是重點，需要理解而不是死記硬背。

相關推薦

1.偏頭痛楊的rocketmq4.x入門之基礎概念掃盲篇

前戲閱讀本文之前，讀者必須自己清楚什麼是訊息佇列，以及訊息佇列的一些基本概念，例如：訊息、生產者、消費者等。我們如果需要玩非同步、分散式事務、程式碼物理解耦、削峰平谷、釋出訂閱等等，可以使用訊息佇列中介

ZigBee入門之基礎概念3

第三講： zigbee術語 射頻收發器：如cc2420 一個節點可以對應多個裝置 一個裝置包含多個端點 每個端點又有很多群集（輸出群集、輸入群集） 每個群集有一個或多個屬性 屬性 Attribute 是一個反映物理數量或狀態的資料值，比如開關值（On/Off） ,溫度值、百

Zigbee入門之基礎概念

大二就開始接觸ZigBee硬體開發確實是一個不小的挑戰，尤其是對一個計算機專業的同學而言。 最近開始寫專案申請書，各種資料看的頭都大了。為了以後更好的進行開發，這次記錄了一些名詞和解釋 上位機和下位機 　　上位機是指可以直接發出操控命令的計算機，一般是PC/hos

RabbitMQ 入門之基礎概念

#### 什麼是訊息佇列（MQ） 訊息是在不同應用間傳遞的資料。這裡的訊息可以非常簡單，比如只包含字串，也可以非常複雜，包含多個巢狀的物件。訊息佇列（Message Queue）簡單來說就是一種應用程式間的通訊方式，訊息傳送後立即返回，然後由訊息系統保證訊息的可靠性傳輸，訊息生產者只需要把訊息發到 MQ 中就

手遊服務端開發基礎概念掃盲篇

13年畢業後，做了一年半web開發，因為受不了在客戶現場工作的氛圍，憤然辭職。轉行做了一名手遊服務端開發。在廣州，據我所知，選擇java作為服務端開發語言的大廠大概有37玩，百田，銀漢，易娛等等。其實遊

1.偏頭痛楊的mysql教學系列之基礎概念篇

前戲 mysql是目前最流行的關係型資料庫之一，在阿里前幾年的去IOE化後整風運動後， mysql從中小型資料庫解決方案成長為了大型網際網路應用關係型資料庫解決方案的中流砥柱。 因為mysql免費且開源，還可以無限擴充套件成N個數據庫叢集，玩分庫分表。 MYSQ

1.偏頭痛楊的中高階java後端面試題攻略系列之java基礎篇（持續更新）

前戲即使不跳槽也建議每隔一段時間出去面試幾次，面試的目的不在於拿offer入職，而是在於你知道你自己目前的水平是幾斤幾兩，是否有被市場所淘汰的危機。終身學習，居安思危，保持危機意識。每個人的時間與精力都是有限的，有限的時間做有限的事情，不要什麼都學，做減法，要有自己的強項，知

Magento 1.x 入門之系列教程一

Magento 1.x 入門教程一 Magento 是一套專業開源的電子商務系統，也是目前主流的外貿網站購物系統，是基於 PHP 語言開發的，資料庫使用的是 Mysql，且瀏覽介面很適合歐美使用者的使用習慣。Magento 設計得非常靈活，具有模組化架構體系和

Cocos2d-x入門之旅[1]場景

在遊戲開發過程中，你可能需要一個主選單，幾個關卡和一個END的介面，如何組織管理這些東西呢？ 和其他遊戲引擎類似，Cocos也使用了場景(Scene) 這個概念 試想象一部電影或是番劇，你不難發現它是被分解為不同場景或不同時間線的，這些部分就是一個又一個的場景 參考：https://www.cnblogs.c

Qt入門之基礎篇 ( 二 ) ：Qt項目建立、編譯、運行和發布過程解析

qt 5 對話 讓我 進度 qmake ctr deploy 設定 設置 轉載請註明出處：CN_Simo。 題解： 　　本篇內容主講Qt應用從創建到發布的整個過程，旨在幫助讀者能夠快速走進Qt的世界。 　　本來計劃是講解Qt源碼靜態編譯，如此的話讀者可能並不能清楚地知

Qt入門之基礎篇 ( 一 ) ：Qt4及Qt5的下載與安裝

mingw ins 第3版 點擊 調試 但我 關系 構建 eas 轉載請註明出處：CN_Simo. 導語： Qt是一個跨平臺的C++圖形界面應用程序框架。它提供給開發者建立圖形用戶界面所需的功能，廣泛用於開發GUI程序，也可用於開發非GUI程序。Qt很容易擴展，並

Redis 入門之基礎

我們 -- git 數量 stack ast www 基礎 技術分享 1.安裝 redis-windows redis服務端下載 redis客戶端下載 redis官網 redis中文網 1.1 Window下安裝 redis-server.exe redis.windo

Java入門之基礎語法碎片知識彙總

## 標題Java入門之基礎語法碎片知識彙總 List item 作為一個前端工程師，主要使用的語言是JavaScript，這是一門動態的弱型別語言。

pytorch 入門之基礎和線性模型入門

一：pytorch基礎 1：張量：Tensor 定義為：多維度的矩陣。 例如： 0維度：點； 一維：向量； 二維：普通矩陣 有torch.FloatTensor ; torch.DoubleTensor; torch.IntTrnsor; 2:變數：Variab

Kears入門之基礎篇

本文轉載自http://www.cnblogs.com/lc1217/p/7132364.html 1.關於Keras         1）簡介               &n

Spring Boot 入門之基礎篇（一）

一、前言 Spring Boot 是由 Pivotal 團隊提供的全新框架，其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。 本系列以快速入門為主，可當作工具小手冊閱讀

ROS入門之基礎功能詳解（二）

前言：本部分主要介紹ros一些基礎功能的使用，包括建立和編譯工作空間，建立和編譯功能包，建立和編譯節點，建立和編譯訊息，建立和編譯服務以及建立launch檔案。 一、建立和編譯工作空間 1.檢視正在使用的工作空間: echo $ROS_PACKAGE_PATH -------------

Kylin入門之基礎解析

原文來自：http://bigdataer.net/?p=2921.概述kylin是一款開源的分散式資料分析工具，基於hadoop之上的sql查詢介面，能支援超大規模的資料分析。響應時間在亞秒級別，其核心是預計算，計算結果存放在hbase中。2.特性可擴充套件超快OLAP引擎

MatConvNet使用入門之基礎篇

深度學習在object tracking中的使用也越來越多，從去年的VOT結果來看，很多tracker都應用了convolution feature，整體效果都比之前的方法提高了一大截，所以學習dee

springboot入門之基礎篇(一)

一、前言Spring Boot 是由 Pivotal 團隊提供的全新框架，其設計目的是用來簡化新 Spring 應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置。本系列以快速入門為主，可當作工具小手冊閱讀二、環境搭建建立一個 maven 工程，目錄結構如下圖