一、消息中間件的使用場(chǎng)景

?

消息中間件的使用場(chǎng)景總結(jié)就是六個(gè)字：解耦、異步、削峰

?

1.解耦

如果我方系統(tǒng)A要與三方B系統(tǒng)進(jìn)行數(shù)據(jù)對(duì)接，推送系統(tǒng)人員信息，通常我們會(huì)使用接口開發(fā)來進(jìn)行。但是如果運(yùn)維期間B系統(tǒng)進(jìn)行了調(diào)整，或者推送過程中B系統(tǒng)網(wǎng)絡(luò)進(jìn)行了調(diào)整，又或者后續(xù)過程中我們需要推送信息到三方C系統(tǒng)中，這樣的話就需要我們進(jìn)行頻繁的接口開發(fā)調(diào)整，還需要考慮接口推送消息失敗的場(chǎng)景。

?

如果我們使用消息中間件進(jìn)行消息推送，我們只需要按照一種約定的數(shù)據(jù)結(jié)構(gòu)進(jìn)行數(shù)據(jù)推送，其他三方系統(tǒng)從消息中間件取值消費(fèi)就可以，即便是三方系統(tǒng)出現(xiàn)宕機(jī)或者其他調(diào)整，我們都可以正常進(jìn)行數(shù)據(jù)推送。

?

總結(jié)：通過一個(gè) MQ，Pub/Sub 發(fā)布訂閱消息這么一個(gè)模型，A 系統(tǒng)就跟其它系統(tǒng)徹底解耦了。

?

2.異步

繼續(xù)我們上述的消息推送業(yè)務(wù)，如果我們現(xiàn)在需要同時(shí)推送消息到BCD三個(gè)系統(tǒng)中，而BCD系統(tǒng)接收到消息后需要進(jìn)行復(fù)雜的邏輯處理，以及讀庫(kù)寫庫(kù)處理。如果一個(gè)三方系統(tǒng)進(jìn)行消息處理需要1s，那我們遍歷推送完一次消息，就需要三秒。

?

而如果我們使用消息中間件，我們只需要推送到消息中間件，然后進(jìn)行接口返回，可能只需要20ms，大大提升了用戶體驗(yàn)。消息推送后BCD系統(tǒng)各自進(jìn)行消息消費(fèi)即可，不需要我們等待。

?

3.削峰

還是上述我們的應(yīng)用場(chǎng)景，假設(shè)某一時(shí)間段內(nèi)，每秒都有一條消息推送，如果我們使用接口進(jìn)行推送，BCD三個(gè)系統(tǒng)處理完就需要三秒。這樣會(huì)導(dǎo)致用戶前端體驗(yàn)較差，而且系統(tǒng)后臺(tái)一直處于阻塞狀態(tài)，后續(xù)的消息推送接口一直在等待。

?

如果我們使用消息中間件，我們只需要將消息推送至消息中間件中，BCD系統(tǒng)對(duì)積壓的消息進(jìn)行相應(yīng)的處理。

?

在上述高頻發(fā)的消息時(shí)間段內(nèi)，會(huì)在消息中間中產(chǎn)生消息積壓，BCD系統(tǒng)在上述時(shí)間段外對(duì)積壓消息進(jìn)行相應(yīng)的處理即可。

?

二、消息中間件的優(yōu)缺點(diǎn)

消息中間件的優(yōu)點(diǎn)其實(shí)就是他的使用場(chǎng)景。

?

消息中間件的缺點(diǎn)與優(yōu)點(diǎn)也是相輔相成的，主要有以下三個(gè)

?

1.系統(tǒng)可用性降低

系統(tǒng)關(guān)聯(lián)的中間件越多，越容易引發(fā)宕機(jī)問題。

?

如上述案例中的問題，原本進(jìn)行消息推送我們只需要開發(fā)接口進(jìn)行推送即可，引入消息中間件后就需要考慮消息中間件的高可用問題，如果消息中間件出現(xiàn)宕機(jī)問題，我們所有的消息推送都會(huì)失敗。

?

2.系統(tǒng)復(fù)雜度提高

上述案例中，如果我們使用接口進(jìn)行消息推送，我們只需要考慮接口超時(shí)以及接口推送消息失敗的問題。但我們引入消息中間件后，就需要考慮消息中間件的維護(hù)，以及消息重復(fù)消費(fèi)，消息丟失的問題。

?

3.一致性問題

上述案例中，如果我們使用接口進(jìn)行消息推送，推送消息我們可以放在事務(wù)中處理，如果推送過程中出現(xiàn)異常，我們可以進(jìn)行數(shù)據(jù)回滾，但我們引入消息中間件后，就需要考慮消息推送后，消費(fèi)失敗的問題，以及如果我們同時(shí)推送消息到BCD系統(tǒng)中，如何保證他們的事務(wù)一致性。

?

三、四種消息中間件的基本介紹

特性 ActiveMQ RabbitMQ RocketMQ Kafka

單機(jī)吞吐量 萬級(jí)，比 RocketMQ、Kafka 低一個(gè)數(shù)量級(jí) 同 ActiveMQ 10 萬級(jí)，支撐高吞吐 10 萬級(jí)，高吞吐，一般配合大數(shù)據(jù)類的系統(tǒng)來進(jìn)行實(shí)時(shí)數(shù)據(jù)計(jì)算、日志采集等場(chǎng)景

topic 數(shù)量對(duì)吞吐量的影響 topic 可以達(dá)到幾百/幾千的級(jí)別，吞吐量會(huì)有較小幅度的下降，這是 RocketMQ 的一大優(yōu)勢(shì)，在同等機(jī)器下，可以支撐大量的 topic topic 從幾十到幾百個(gè)時(shí)候，吞吐量會(huì)大幅度下降，在同等機(jī)器下，Kafka 盡量保證 topic 數(shù)量不要過多，如果要支撐大規(guī)模的 topic，需要增加更多的機(jī)器資源

時(shí)效性 ms 級(jí) 微秒級(jí)，這是 RabbitMQ 的一大特點(diǎn)，延遲最低 ms 級(jí) 延遲在 ms 級(jí)以內(nèi)

可用性 高，基于主從架構(gòu)實(shí)現(xiàn)高可用 同 ActiveMQ 非常高，分布式架構(gòu) 非常高，分布式，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用

消息可靠性 有較低的概率丟失數(shù)據(jù) 基本不丟 經(jīng)過參數(shù)優(yōu)化配置，可以做到 0 丟失 同 RocketMQ

功能支持 MQ 領(lǐng)域的功能極其完備 基于 erlang 開發(fā)，并發(fā)能力很強(qiáng)，性能極好，延時(shí)很低 MQ 功能較為完善，還是分布式的，擴(kuò)展性好 功能較為簡(jiǎn)單，主要支持簡(jiǎn)單的 MQ 功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用

其他 Apache軟件基金會(huì)開發(fā)、起步較早，但沒有經(jīng)過大量吞吐場(chǎng)景驗(yàn)證，目前社區(qū)不是很活躍 開源，穩(wěn)定，社區(qū)活躍度高 阿里出品，目前已交給Apache，但社區(qū)活躍度較低 Apache軟件基金會(huì)開發(fā)、開源、高通吐量，社區(qū)活躍度高

1.ActiveMQ

1.1：Activemq 是什么

Activemq 是一種開源的，實(shí)現(xiàn)了JMS1.1規(guī)范的，面向消息(MOM)的中間件，為應(yīng)用程序提供高效的、可擴(kuò)展的、穩(wěn)定的和安全的企業(yè)級(jí)消息通信。

?

1.2：Activemq 的作用及原理

Activemq 的作用就是系統(tǒng)之間進(jìn)行通信，原理就是生產(chǎn)者生產(chǎn)消息， 把消息發(fā)送給activemq， Activemq 接收到消息， 然后查看有多少個(gè)消費(fèi)者，

?

然后把消息轉(zhuǎn)發(fā)給消費(fèi)者， 此過程中生產(chǎn)者無需參與。 消費(fèi)者接收到消息后做相應(yīng)的處理和生產(chǎn)者沒有任何關(guān)系。

?

1.3：Activemq 的通信方式

publish(發(fā)布)-subscribe(訂閱)(發(fā)布-訂閱方式)

發(fā)布/訂閱方式用于多接收客戶端的方式，作為發(fā)布訂閱的方式，可能存在多個(gè)接收客戶端，并且接收端客戶端與發(fā)送客戶端存在時(shí)間上的依賴。一個(gè)接收端只能接收他創(chuàng)建以后發(fā)送客戶端發(fā)送的信息。

?

p2p(point-to-point)(點(diǎn)對(duì)點(diǎn))

p2p的過程則理解起來比較簡(jiǎn)單。它好比是兩個(gè)人打電話，這兩個(gè)人是獨(dú)享這一條通信鏈路的。一方發(fā)送消息，另外一方接收，就這么簡(jiǎn)單。在實(shí)際應(yīng)用中因?yàn)橛卸鄠€(gè)用戶對(duì)使用p2p的鏈路，相互通信的雙方是通過一個(gè)類似于隊(duì)列的方式來進(jìn)行交流。和前面pub-sub的區(qū)別在于一個(gè)topic有一個(gè)發(fā)送者和多個(gè)接收者，而在p2p里一個(gè)queue只有一個(gè)發(fā)送者和一個(gè)接收者。

?

1.4：Activemq 的消息持久化機(jī)制

JDBC： 持久化到數(shù)據(jù)庫(kù)

AMQ ：日志文件（已基本不用）

KahaDB ： AMQ基礎(chǔ)上改進(jìn)，默認(rèn)選擇

LevelDB ：谷歌K/V數(shù)據(jù)庫(kù)

在activemq.xml中查看默認(rèn)的broker持久化機(jī)制。

?

1.5：Activemq 的消息確認(rèn)機(jī)制

（1）AUTO_ACKNOWLEDGE = 1 自動(dòng)確認(rèn)

?

（2）CLIENT_ACKNOWLEDGE = 2 客戶端手動(dòng)確認(rèn)

?

（3）DUPS_OK_ACKNOWLEDGE = 3 自動(dòng)批量確認(rèn)

?

（4）SESSION_TRANSACTED = 0 事務(wù)提交并確認(rèn)

?

（5）INDIVIDUAL_ACKNOWLEDGE = 4 單條消息確認(rèn)

?

前四種是JMS API中提供的客戶端ACK_MODE。第五種是InforSuiteMQ自定義補(bǔ)充的一種ACK_MODE。

?

2.RabbitMQ

2.1：RabbitMQ是什么

RabbitMQ是一個(gè)由erlang語言編寫的、開源的、在AMQP基礎(chǔ)上完整的、可復(fù)用的企業(yè)消息系統(tǒng)。

?

2.2：RabbitMQ的作用及原理

?

?

基本概念

?

關(guān)鍵名稱 說明

Channel（信道） 消息推送使用的通道

Producer（消息的生產(chǎn)者） 向消息隊(duì)列發(fā)布消息的客戶端應(yīng)用程序

Consumer（消息的消費(fèi)者） 從消息隊(duì)列取得消息的客戶端應(yīng)用程序

Message（消息） 消息由消息頭和消息體組成

Routing Key（路由鍵） 消息頭的一個(gè)屬性，用于標(biāo)記消息的路由規(guī)則，決定了交換機(jī)的轉(zhuǎn)發(fā)路徑

Queue（消息隊(duì)列） 用于存儲(chǔ)生產(chǎn)者的消息

Exchange（交換器路由器） 提供Producer到Queue之間的匹配

Binding（綁定） 用于建立Exchange和Queue之間的關(guān)聯(lián)

Binding Key（綁定鍵） Exchange與Queue的綁定關(guān)系，用于匹配Routing Key

Broker（服務(wù)主體） RabbitMQ Server，服務(wù)器實(shí)體

2.3：RabbitMQ的通信方式

2.3.1：簡(jiǎn)單隊(duì)列

最簡(jiǎn)單的工作隊(duì)列，其中一個(gè)消息生產(chǎn)者，一個(gè)消息消費(fèi)者，一個(gè)隊(duì)列。也稱為點(diǎn)對(duì)點(diǎn)模式

?

2.3.2：工作隊(duì)列模式

一個(gè)消息生產(chǎn)者，一個(gè)交換器，一個(gè)消息隊(duì)列，多個(gè)消費(fèi)者。同樣也稱為點(diǎn)對(duì)點(diǎn)模式

?

2.3.3：發(fā)布訂閱模式

Pulish/Subscribe，無選擇接收消息，一個(gè)消息生產(chǎn)者，一個(gè)交換機(jī)（交換機(jī)類型為fanout），多個(gè)消息隊(duì)列，多個(gè)消費(fèi)者

?

生產(chǎn)者只需把消息發(fā)送到交換機(jī)，綁定這個(gè)交換機(jī)的隊(duì)列都會(huì)獲得一份一樣的數(shù)據(jù)。

?

2.3.4：路由模式

在發(fā)布/訂閱模式的基礎(chǔ)上，有選擇的接收消息，也就是通過 routing 路由進(jìn)行匹配條件是否滿足接收消息。

?

2.3.5：主體模式

topics(主題)模式跟routing路由模式類似，只不過路由模式是指定固定的路由鍵 routingKey，而主題模式是可以模糊匹配路由鍵 routingKey，類似于SQL中 = 和 like 的關(guān)系。

?

2.3.6：RPC模式

與上面其他5種所不同之處，該模式是擁有請(qǐng)求/回復(fù)的。也就是有響應(yīng)的，上面5種都沒有。

?

RPC是指遠(yuǎn)程過程調(diào)用，也就是說兩臺(tái)服務(wù)器A，B，一個(gè)應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的處理業(yè)務(wù)，處理完后然后在A服務(wù)器繼續(xù)執(zhí)行下去，把異步的消息以同步的方式執(zhí)行。

?

2.4：RabbitMQ的消息持久化機(jī)制

Queue（消息隊(duì)列）的持久化是通過durable=true來實(shí)現(xiàn)的。

?

Message（消息）的持久化 ，通過設(shè)置消息是持久化的標(biāo)識(shí)。

?

Exchange（交換機(jī)）的持久化 。

?

2.5：RabbitMQ的消息確認(rèn)機(jī)制

confirm機(jī)制：確認(rèn)消息是否成功發(fā)送到Exchange

?

ack機(jī)制：確認(rèn)消息是否被消費(fèi)者成功消費(fèi)

?

AcknowledgeMode.NONE：自動(dòng)確認(rèn)

AcknowledgeMode.AUTO：根據(jù)情況確認(rèn)

AcknowledgeMode.MANUAL：手動(dòng)確認(rèn)

3.RocketMQ

3.1：RocketMQ是什么

RocketMQ是阿里開發(fā)的一款純java、分布式、隊(duì)列模型的開源消息中間件，支持事務(wù)消息、順序消息、批量消息、定時(shí)消息、消息回溯等。

?

3.2：RocketMQ的作用及原理

?

?

基本概念

?

關(guān)鍵名稱 說明

Producer 消息生產(chǎn)者

Producer Group 生產(chǎn)者組

Consumer 消息消費(fèi)者

Consumer Group 消費(fèi)者組

Topic Topic用于將消息按主題做劃分，Producer將消息發(fā)往指定的Topic，Consumer訂閱該Topic就可以收到這條消息

Message 代表一條消息

Tag 標(biāo)簽可以被認(rèn)為是對(duì) Topic 進(jìn)一步細(xì)化

Broker 負(fù)責(zé)接收并存儲(chǔ)消息

Queue Topic和Queue是1對(duì)多的關(guān)系，一個(gè)Topic下可以包含多個(gè)Queue，主要用于負(fù)載均衡

Offset RocketMQ在存儲(chǔ)消息時(shí)會(huì)為每個(gè)Topic下的每個(gè)Queue生成一個(gè)消息的索引文件，每個(gè)Queue都對(duì)應(yīng)一個(gè)Offset記錄當(dāng)前Queue中消息條數(shù)。

NameServer NameServer可以看作是RocketMQ的注冊(cè)中心

3.3：RocketMQ的通信方式

RocketMQ消息訂閱有兩種模式

?

一種是Push模式（MQPushConsumer），即MQServer主動(dòng)向消費(fèi)端推送

?

另外一種是Pull模式（MQPullConsumer），即消費(fèi)端在需要時(shí)，主動(dòng)到MQ Server拉取

?

但在具體實(shí)現(xiàn)時(shí)，Push和Pull模式本質(zhì)都是采用消費(fèi)端主動(dòng)拉取的方式，即consumer輪詢從broker拉取消息

?

集群模式和廣播模式

?

集群模式：默認(rèn)情況下我們都是使用的集群模式，也就是說消費(fèi)者組收到消息后，只有其中的一臺(tái)機(jī)器會(huì)接收到消息。

?

廣播模式：消費(fèi)者組內(nèi)的每臺(tái)機(jī)器都會(huì)收到這條消息。

?

3.文章來源地址http://www.zghlxwxcb.cn/news/detail-743683.html

到了這里，關(guān)于ActiveMQ、RabbitMQ、RocketMQ、Kafka介紹的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！