一、消息中間件的使用場景

?

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

?

1.解耦

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

?

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

?

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

?

2.異步

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

?

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

?

3.削峰

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

?

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

?

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

?

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

消息中間件的優(yōu)點其實就是他的使用場景。

?

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

?

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

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

?

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

?

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

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

?

3.一致性問題

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

?

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

特性 ActiveMQ RabbitMQ RocketMQ Kafka

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

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

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

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

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

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

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

1.ActiveMQ

1.1：Activemq 是什么

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

?

1.2：Activemq 的作用及原理

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

?

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

?

1.3：Activemq 的通信方式

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

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

?

p2p(point-to-point)(點對點)

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

?

1.4：Activemq 的消息持久化機制

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

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

KahaDB ： AMQ基礎(chǔ)上改進，默認選擇

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

在activemq.xml中查看默認的broker持久化機制。

?

1.5：Activemq 的消息確認機制

（1）AUTO_ACKNOWLEDGE = 1 自動確認

?

（2）CLIENT_ACKNOWLEDGE = 2 客戶端手動確認

?

（3）DUPS_OK_ACKNOWLEDGE = 3 自動批量確認

?

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

?

（5）INDIVIDUAL_ACKNOWLEDGE = 4 單條消息確認

?

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

?

2.RabbitMQ

2.1：RabbitMQ是什么

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

?

2.2：RabbitMQ的作用及原理

?

?

基本概念

?

關(guān)鍵名稱 說明

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

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

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

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

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

Queue（消息隊列） 用于存儲生產(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ù)器實體

2.3：RabbitMQ的通信方式

2.3.1：簡單隊列

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

?

2.3.2：工作隊列模式

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

?

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

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

?

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

?

2.3.4：路由模式

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

?

2.3.5：主體模式

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

?

2.3.6：RPC模式

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

?

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

?

2.4：RabbitMQ的消息持久化機制

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

?

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

?

Exchange（交換機）的持久化 。

?

2.5：RabbitMQ的消息確認機制

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

?

ack機制：確認消息是否被消費者成功消費

?

AcknowledgeMode.NONE：自動確認

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

AcknowledgeMode.MANUAL：手動確認

3.RocketMQ

3.1：RocketMQ是什么

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

?

3.2：RocketMQ的作用及原理

?

?

基本概念

?

關(guān)鍵名稱 說明

Producer 消息生產(chǎn)者

Producer Group 生產(chǎn)者組

Consumer 消息消費者

Consumer Group 消費者組

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

Message 代表一條消息

Tag 標(biāo)簽可以被認為是對 Topic 進一步細化

Broker 負責(zé)接收并存儲消息

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

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

NameServer NameServer可以看作是RocketMQ的注冊中心

3.3：RocketMQ的通信方式

RocketMQ消息訂閱有兩種模式

?

一種是Push模式（MQPushConsumer），即MQServer主動向消費端推送

?

另外一種是Pull模式（MQPullConsumer），即消費端在需要時，主動到MQ Server拉取

?

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

?

集群模式和廣播模式

?

集群模式：默認情況下我們都是使用的集群模式，也就是說消費者組收到消息后，只有其中的一臺機器會接收到消息。

?

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

?

3.