java基礎教程欄目今天詳細介紹有關RocketMQ知識。
又是好久沒有寫博客了,雖然可以找出無數(shù)個沒有寫的博客的理由,但是說到底,還是一個字“懶”。今天我終于吃了一顆治療懶癌的藥丸,決定寫一篇博客。介紹什么好呢,思來想去,還是介紹下RocketMQ吧,畢竟寫了30多篇博客,還沒有好好寫過關于MQ的博客呢。本篇博客比較基礎,不涉及到源碼分析,只是掃盲。
MQ有什么用
解耦
我覺得從某種角度來說,微服務促進了MQ的蓬勃發(fā)展,本來一個系統(tǒng)有N多個模塊,所有模塊都強耦合在一起,現(xiàn)在微服務了,一個模塊就是一個系統(tǒng),系統(tǒng)之間肯定需要交互,交互有三種常見的方法,一種是RPC,一種是HTTP,一種就是MQ了。
異步
原本一個業(yè)務分為N步,要一步一步處理,才能把最終的結果返回給用戶,現(xiàn)在有了MQ,先把最關鍵的部分處理完畢,然后發(fā)送消息到MQ,直接返回給用戶OK,至于后面的步驟在后臺慢慢處理吧,真乃提升用戶體驗的神器。
削峰
某個接口的請求量突然飆升,勢必會對應用服務器、數(shù)據(jù)庫服務器造成很大的壓力,現(xiàn)在有了MQ,來多少請求都不在怕的,后臺慢慢處理唄。
RocketMQ簡介
RocketMQ是用Java編寫的,是阿里開源的消息中間件,吸收了Kafka很多優(yōu)點。Kafka也是比較熱門的消息中間件,不過Kafka是用Scala編寫的,不利于Java程序員去閱讀源碼,也不利于Java程序員做一些定制化的開發(fā)。接觸過Kafka的小伙伴都知道,要用好Kafka實屬不易,相對來說,RocketMQ簡單多了,而且RocketMQ有阿里加持,經(jīng)歷了N次雙11的考驗,比較適合國內(nèi)互聯(lián)網(wǎng)公司,所以國內(nèi)使用RocketMQ的公司很多。
RocketMQ四大組件
圖片來自gitee.com/mirrors/roc…
可以看到RocketMQ主要有四個組件:
NameServer
- 無狀態(tài)服務,注冊中心,可集群部署,但是NameServer節(jié)點之間沒有任何數(shù)據(jù)交互。
- Borker會以定時把Topic路由信息上報給所有的NameServer。Producer、Consumer會隨機選擇一個NameServer定時Topic更新路由信息。
- Topic路由信息在NameServer集群中采用最終一致性。
- 保證AP。
Borker
- RocketMQ的服務端,用于存儲消息、分發(fā)消息。
- Borker會定時把自身擁有的所有的Topic路由信息上報給NameServer。
- Borker有兩個角色:Master、Follower,Master承擔讀(消費消息)寫(生產(chǎn)消息)操作,如果Master比較忙,或者不可用,F(xiàn)ollower可以承擔讀操作。BorkerId=0,代表是Matser,BorkerId!=0,代表是Follower,需要注意的有兩點: 其一,目前為止,BorkerId=1的Follower才可以承擔讀操作; 其二,只有較高版本的RocketMQ才支持當Master節(jié)點掛掉,F(xiàn)ollower自動升級到Master。
Producer
生產(chǎn)者,每隔一定時間向NameServer發(fā)起Topic的路由信息查詢。
Consumer
消費者,每隔一定時間向NameServer發(fā)起Topic的路由信息查詢。
為什么注冊中心不選用Zookeeper
其實,在低版本的RocketMQ中,確實是選用Zookeeper作為注冊中心的,但是后面改成了現(xiàn)在的NameServer,猜想主要原因是:
- RocketMQ已經(jīng)是一個中間件了,不想再依賴其他中間件。
- Zookeeper比較重,有很多功能RocketMQ是用不到的,不如寫一個輕量級的注冊中心。
- Zookeeper是CP,一旦觸發(fā)領導選舉,那么注冊中心就不可用了,而RocketMQ的注冊中心,不需要強一致性,只要保證最終一致性。
RocketMQ消息領域模型
Message
- 傳輸?shù)南ⅰ?/li>
- 消息必須有Topic。
- 消息可以有多個Tag和多個Key,可以看做消息的附加屬性。
Topic
- 一類消息的集合。
- 每個消息必須有一個Topic。
- 消息的第一級類型。
Tag
- 一個消息除了有Topic之外,還可以有Tag,用來細分同一個Topic下的不同種類的消息。
- Tag不是必須的。
- 消息的第二級類型。
Group
分為ProducerGroup,ConsumerGroup,我們