資訊專欄INFORMATION COLUMN
摘要：和之間的關(guān)系通過來綁定，來定義，即相同的，等于表示節(jié)點，非表示節(jié)點。所有的節(jié)點與集群的所有節(jié)點保持長連接，定時注冊信息到所有的。對磁盤的訪問串行化，避免磁盤竟?fàn)?，不會因為隊列增加?dǎo)致增高。要保證與完全的一致，增加了編程的復(fù)雜度。
Apache RocketMQ?是一個開源的分布式消息和流數(shù)據(jù)平臺。
1、既然是消息系統(tǒng)，最核心的功能就是要提供消息的發(fā)布與訂閱功能，最簡單的概念模型如下：
但是rocketmq提供的能力會比這個復(fù)雜的多，如一個生產(chǎn)方發(fā)布消息，需要多個消費方訂閱，也會存在多個生產(chǎn)方生產(chǎn)消息，一個消費方消費消息，出現(xiàn)一對多，多對一的情況。
上圖就是擴展了producer、consumer和Topic的概念模型，rocketmq最核心的概念就是Tpoic，producer和consumer都是圍繞Topic展開，每個broker下可以有多個topic，topic下又可以有很對隊列messageQueue，相同的topic又可以分布在不同broker節(jié)點下，producer發(fā)送消息會輪訓(xùn)的發(fā)送到topic的隊列下；相同consumer分組是負(fù)載均衡訂閱消息，不同的consumer分組之間互不干擾，即使廣播訂閱消息；同一Topic下的每個隊列只能被相同分組下的一個consumer訂閱消費，但一個consumer可以消費多個隊列。
2、整體部署架構(gòu)圖
nameserver是幾乎沒有狀態(tài)的節(jié)點，可以集群部署，節(jié)點之間也沒有任何數(shù)據(jù)同步。
broker的部署相對復(fù)雜，是一個數(shù)據(jù)分散集群，分master和slave，每個master存儲一部分?jǐn)?shù)據(jù)，為了數(shù)據(jù)的高可用，每個master節(jié)點可以有多個slave節(jié)點，master之間無數(shù)據(jù)同步，master與slave之間有數(shù)據(jù)同步。master和slave之間的關(guān)系通過brokerName來綁定，brokerId來定義，即相同的brokerName，brokerId等于0表示master節(jié)點，非0表示slave節(jié)點。所有的broker節(jié)點與nameserver集群的所有節(jié)點保持長連接，定時注冊Topic信息到所有的nameserver。
producer與nameserver集群中的一臺（隨機）保持長連接，定時獲取Topic路由信息，并且與提供Topic服務(wù)的broker的master節(jié)點保持長連接，并定時發(fā)送心跳，producer集群也是無狀態(tài)的，可以集群部署。
consumer與nameserver集群中的一臺（隨機）保持長連接，定時獲取Topic路由信息，并且向提供Topic的broker的master和slave節(jié)點都保持長連接，并定時發(fā)送心跳，Consumer既可以從 Master 訂閱消息，也可以從 Slave 訂閱消息，訂閱規(guī)則由 Broker 配置決定，consumer也是集群的部署的，負(fù)載均衡的消費Topic的消息。
3、消息的存儲模型
rocketmq的消息存儲與消費隊列是分開的，消息被存儲在commitLog下，然后再異步構(gòu)建消費隊列messageQueue，消費隊列并不存儲真正的消息內(nèi)容，只是存儲消息在commitLog下的偏移量、消息的長度和消息的tag的hashcode。如圖所示：
所有數(shù)據(jù)多帶帶存儲到一個 Commit Log，完全順序?qū)?，隨機讀。
對最終用戶展現(xiàn)的隊列實際只存儲消息在 Commit Log 的位置信息，并且串行方式刷盤。
這樣設(shè)計有以下優(yōu)勢：
隊列輕量化，單個隊列數(shù)據(jù)量非常少。
對磁盤的訪問串行化，避免磁盤竟?fàn)?，不會因為隊列增加?dǎo)致 IOWAIT 增高。
但也存在以下缺點：
寫雖然完全是順序?qū)?，但是讀卻變成了完全的隨機讀。
讀一條消息，會先讀 Consume Queue，再讀 Commit Log，增加了開銷。
要保證 Commit Log 與 Consume Queue 完全的一致，增加了編程的復(fù)雜度。
4、rocketmq具有以下特點
能夠保證嚴(yán)格的消息順序
提供豐富的消息拉取模式
高效的訂閱者水平擴展能力
實時的消息訂閱機制
億級消息堆積能力
與其他消息隊列系統(tǒng)的一個對比如下：
| 消息產(chǎn)品 | 支持客戶端 | 協(xié)議和規(guī)范 | 順序消息 | 定時消息 | 批量消息 | 廣播消息 | 消息過濾 | 消息回溯 | 消息優(yōu)先級 | 高可用和故障切換 | 消息追蹤 | 配置 | 管理和操作工具 | Server Triggered Redelivery | 消息存儲 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ActiveMQ | java,c++,php,net | 推模型，支持 OpenWire, STOMP, AMQP, MQTT, JMS | 獨占消費和消息分組支持順序 | 支持 | 不支持 | 支持 | 支持 | 支持 | 支持 | 支持，leveldb+zookeeper | 不支持 | 默認(rèn)配置是低級別的，用戶需要優(yōu)化配置參數(shù) | 支持 | 不支持 | 支持JDBC,leveldb,kahadb |
| Kafka | java,scala | 拉模型, 支持TCP | 分區(qū)內(nèi)消息有順序 | 不支持 | 支持異步生產(chǎn)者 | 不支持 | 支持 | 支持 | 不支持 | 支持，依賴zookeeper | 不支持 | Kafka使用鍵值對格式進(jìn)行配置。這些值可以通過文件提供，也可以通過編程方式提供 | 支持，使用命令行 | 不支持 | 高性能文件存儲 |
| RocketMQ | java,c++,go | 拉模型, 支持TCP, JMS, OpenMessaging | 確保消息的嚴(yán)格順序，并可以優(yōu)雅地擴展 | 支持 | 支持同步模式，以避免消息丟失 | 支持 | 支持 | 支持按時間和偏移量 | 不支持 | 支持主從模式 | 支持 | 開箱即用，用戶只需注意一些配置 | 支持，命令行和web客戶端 | 支持 | 高性能和低延遲的文件存儲 |
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/77214.html
摘要：每個記錄完整的路由信息，提供相應(yīng)的讀寫服務(wù)，并支持快速存儲擴展。此外，提供災(zāi)難恢復(fù)，豐富的指標(biāo)統(tǒng)計數(shù)據(jù)和警報機制，而傳統(tǒng)的消息傳遞系統(tǒng)都缺乏這些機制。發(fā)送過程支持并具有低延遲。 概覽 Apache RocketMQ是一款具有低延遲，高性能和可靠性，數(shù)十億容量和靈活可擴展性的分布式消息傳遞和流媒體平臺。它由四部分組成：Name Servers，brokers，producers和cons...
摘要：通過以上分析我們可以得出消息隊列具有很好的削峰作用的功能即通過異步處理，將短時間高并發(fā)產(chǎn)生的事務(wù)消息存儲在消息隊列中，從而削平高峰期的并發(fā)事務(wù)。 該文已加入開源項目：JavaGuide（一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目，Star 數(shù)接近 16k）。地址:https://github.com/Snailclimb... 本文內(nèi)容思維導(dǎo)圖：showImg(ht...
摘要：最近對基礎(chǔ)教程系列的催更比較多，說一下最近的近況因為打算一起更新。再次，對于中國用戶來說，還有一個非常特殊的意義它將曾經(jīng)紅極一時的，以及阿里巴巴的強力消息中間件融入體系。 最近對《Spring Cloud Alibaba基礎(chǔ)教程》系列的催更比較多，說一下最近的近況：因為打算Spring Boot 2.x一起更新。所以一直在改博客Spring Boot專題頁和Git倉庫的組織。由于前端技...
閱讀 3649·2021-09-13 10:28
閱讀 1995·2021-08-10 09:43
閱讀 1060·2019-08-30 15:44
閱讀 3247·2019-08-30 13:14
閱讀 1936·2019-08-29 16:56
閱讀 2997·2019-08-29 16:35
閱讀 2903·2019-08-29 12:58
閱讀 922·2019-08-26 13:46
