java基礎(chǔ)教程欄目今天詳細(xì)介紹有關(guān)RocketMQ知識(shí)。

又是好久沒(méi)有寫博客了，雖然可以找出無(wú)數(shù)個(gè)沒(méi)有寫的博客的理由，但是說(shuō)到底，還是一個(gè)字“懶”。今天我終于吃了一顆治療懶癌的藥丸，決定寫一篇博客。介紹什么好呢，思來(lái)想去，還是介紹下RocketMQ吧，畢竟寫了30多篇博客，還沒(méi)有好好寫過(guò)關(guān)于MQ的博客呢。本篇博客比較基礎(chǔ)，不涉及到源碼分析，只是掃盲。

MQ有什么用

解耦

我覺(jué)得從某種角度來(lái)說(shuō)，微服務(wù)促進(jìn)了MQ的蓬勃發(fā)展，本來(lái)一個(gè)系統(tǒng)有N多個(gè)模塊，所有模塊都強(qiáng)耦合在一起，現(xiàn)在微服務(wù)了，一個(gè)模塊就是一個(gè)系統(tǒng)，系統(tǒng)之間肯定需要交互，交互有三種常見(jiàn)的方法，一種是RPC，一種是HTTP，一種就是MQ了。

異步

原本一個(gè)業(yè)務(wù)分為N步，要一步一步處理，才能把最終的結(jié)果返回給用戶，現(xiàn)在有了MQ，先把最關(guān)鍵的部分處理完畢，然后發(fā)送消息到MQ，直接返回給用戶OK，至于后面的步驟在后臺(tái)慢慢處理吧，真乃提升用戶體驗(yàn)的神器。

削峰

某個(gè)接口的請(qǐng)求量突然飆升，勢(shì)必會(huì)對(duì)應(yīng)用服務(wù)器、數(shù)據(jù)庫(kù)服務(wù)器造成很大的壓力，現(xiàn)在有了MQ，來(lái)多少請(qǐng)求都不在怕的，后臺(tái)慢慢處理唄。

RocketMQ簡(jiǎn)介

RocketMQ是用Java編寫的，是阿里開(kāi)源的消息中間件，吸收了Kafka很多優(yōu)點(diǎn)。Kafka也是比較熱門的消息中間件，不過(guò)Kafka是用Scala編寫的，不利于Java程序員去閱讀源碼，也不利于Java程序員做一些定制化的開(kāi)發(fā)。接觸過(guò)Kafka的小伙伴都知道，要用好Kafka實(shí)屬不易，相對(duì)來(lái)說(shuō)，RocketMQ簡(jiǎn)單多了，而且RocketMQ有阿里加持，經(jīng)歷了N次雙11的考驗(yàn)，比較適合國(guó)內(nèi)互聯(lián)網(wǎng)公司，所以國(guó)內(nèi)使用RocketMQ的公司很多。

RocketMQ四大組件

圖片來(lái)自gitee.com/mirrors/roc…

可以看到RocketMQ主要有四個(gè)組件：

NameServer

• 無(wú)狀態(tài)服務(wù)，注冊(cè)中心，可集群部署，但是NameServer節(jié)點(diǎn)之間沒(méi)有任何數(shù)據(jù)交互。
• Borker會(huì)以定時(shí)把Topic路由信息上報(bào)給所有的NameServer。Producer、Consumer會(huì)隨機(jī)選擇一個(gè)NameServer定時(shí)Topic更新路由信息。
• Topic路由信息在NameServer集群中采用最終一致性。
• 保證AP。

Borker

• RocketMQ的服務(wù)端，用于存儲(chǔ)消息、分發(fā)消息。
• Borker會(huì)定時(shí)把自身?yè)碛械乃械腡opic路由信息上報(bào)給NameServer。
• Borker有兩個(gè)角色：Master、Follower，Master承擔(dān)讀（消費(fèi)消息）寫（生產(chǎn)消息）操作，如果Master比較忙，或者不可用，F(xiàn)ollower可以承擔(dān)讀操作。BorkerId=0，代表是Matser，BorkerId!=0，代表是Follower，需要注意的有兩點(diǎn)： 其一，目前為止，BorkerId=1的Follower才可以承擔(dān)讀操作； 其二，只有較高版本的RocketMQ才支持當(dāng)Master節(jié)點(diǎn)掛掉，F(xiàn)ollower自動(dòng)升級(jí)到Master。

Producer

生產(chǎn)者，每隔一定時(shí)間向NameServer發(fā)起Topic的路由信息查詢。

Consumer

消費(fèi)者，每隔一定時(shí)間向NameServer發(fā)起Topic的路由信息查詢。

為什么注冊(cè)中心不選用Zookeeper

其實(shí)，在低版本的RocketMQ中，確實(shí)是選用Zookeeper作為注冊(cè)中心的，但是后面改成了現(xiàn)在的NameServer，猜想主要原因是：

• RocketMQ已經(jīng)是一個(gè)中間件了，不想再依賴其他中間件。
• Zookeeper比較重，有很多功能RocketMQ是用不到的，不如寫一個(gè)輕量級(jí)的注冊(cè)中心。
• Zookeeper是CP，一旦觸發(fā)領(lǐng)導(dǎo)選舉，那么注冊(cè)中心就不可用了，而RocketMQ的注冊(cè)中心，不需要強(qiáng)一致性，只要保證最終一致性。

RocketMQ消息領(lǐng)域模型

Message

• 傳輸?shù)南ⅰ?/li>
• 消息必須有Topic。
• 消息可以有多個(gè)Tag和多個(gè)Key，可以看做消息的附加屬性。

Topic

• 一類消息的集合。
• 每個(gè)消息必須有一個(gè)Topic。
• 消息的第一級(jí)類型。

Tag

• 一個(gè)消息除了有Topic之外，還可以有Tag，用來(lái)細(xì)分同一個(gè)Topic下的不同種類的消息。
• Tag不是必須的。
• 消息的第二級(jí)類型。

Group

分為ProducerGroup，ConsumerGroup，我們