一、 消息中間件
簡介
消息中間件利用高效可靠的消息傳遞機制進行平臺無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。通過提供消息傳遞和消息排隊模型，它可以在分布式環(huán)境下擴展進程間的通信。
使用環(huán)境
消息中間件適用于需要可靠的數(shù)據(jù)傳送的分布式環(huán)境。采用消息中間件機制的系統(tǒng)中，不同的對象之間通過傳遞消息來激活對方的事件，完成相應(yīng)的操作。發(fā)送者將消息發(fā)送給消息服務(wù)器，消息服務(wù)器將消息存放在若干隊列中，在合適的時候再將消息轉(zhuǎn)發(fā)給接收者。消息中間件能在不同平臺之間通信，它常被用來屏蔽掉各種平臺及協(xié)議之間的特性，實現(xiàn)應(yīng)用程序之間的協(xié)同，其優(yōu)點在于能夠在客戶和服務(wù)器之間提供同步和異步的連接，并且在任何時刻都可以將消息進行傳送或者存儲轉(zhuǎn)發(fā)，這也是它比遠程過程調(diào)用更進一步的原因。
二、MQ消息中間件
MQ全稱 Message Queue（消息隊列），是在消息的傳輸過程中保存消息的容器。它是應(yīng)用程序和應(yīng)用程序之間的通信方法。
三、為什么要使用MQ
在項目中，可將一些無需即時返回且耗時的操作提取出來，進行異步處理，而這種異步處理的方式大大的節(jié)省了服務(wù)器的請求響應(yīng)時間，從而提高了系統(tǒng)的吞吐量。
MQ總結(jié)為三個好處:
(1) 應(yīng)用解耦
以電商應(yīng)用為例，應(yīng)用中有訂單系統(tǒng)、庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)。用戶創(chuàng)建訂單后，如果耦合調(diào)用庫存系統(tǒng)、物流系統(tǒng)、支付系統(tǒng)，任何一個子系統(tǒng)出了故障，都會造成下單操作異常。當轉(zhuǎn)變成基于消息隊列的方式后，系統(tǒng)間調(diào)用的問題會減少很多，比如物流系統(tǒng)因為發(fā)生故障，需要幾分鐘來修復(fù)。在這幾分鐘的時間里，物流系統(tǒng)要處理的內(nèi)容被緩存在消息隊列中，用戶的下單操作可以正常完成。當物流系統(tǒng)恢復(fù)后，繼續(xù)處理訂單信息即可，中間用戶感受不到物流系統(tǒng)的故障，提升系統(tǒng)的可用性。
(2)異步提速
上面要完成下單需要花費的時間： 20 + 300 + 300 + 300 = 920ms 用戶點擊完下單按鈕后，需要等待920ms才能得到下單響應(yīng)，太慢！
使用MQ可以解決上述問題
用戶點擊完下單按鈕后，只需等待25ms就能得到下單響應(yīng) (20 + 5 = 25ms)。
提升用戶體驗和系統(tǒng)吞吐量（單位時間內(nèi)處理請求的數(shù)目）。
(3)削峰填谷
? 舉個例子，如果訂單系統(tǒng)最多能處理一千次訂單，這個處理能力應(yīng)付正常時段的下單時綽綽有余，正常時段我們下單一秒后就能返回結(jié)果。但是在高峰期，如果有兩千次下單操作系統(tǒng)是處理不了的，只能限制訂單超過一千后不允許用戶下單。使用消息隊列做緩沖，我們可以取消這個限制，把一秒內(nèi)下的訂單分散成一段時間來處理，這時有些用戶可能在下單十幾秒后才能收到下單成功的操作，但是比不能下單的體驗要好。
簡單來說： 就是在訪問量劇增的情況下，但是應(yīng)用仍然不能停，比如“雙十一”下單的人多，但是淘寶這個應(yīng)用仍然要運行，所以就可以使用消息中間件采用隊列的形式減少突然訪問的壓力
使用了 MQ 之后，限制消費消息的速度為1000，這樣一來，高峰期產(chǎn)生的數(shù)據(jù)勢必會被積壓在 MQ 中，高峰就被“削”掉了，但是因為消息積壓，在高峰期過后的一段時間內(nèi)，消費消息的速度還是會維持在1000，直到消費完積壓的消息，這就叫做“填谷”。
使用MQ后，可以提高系統(tǒng)穩(wěn)定性。
MQ的缺點
-
系統(tǒng)可用性降低
系統(tǒng)引入的外部依賴越多，系統(tǒng)穩(wěn)定性越差。一旦 MQ 宕機，就會對業(yè)務(wù)造成影響。如何保證MQ的高可用？ -
系統(tǒng)復(fù)雜度提高
MQ 的加入大大增加了系統(tǒng)的復(fù)雜度，以前系統(tǒng)間是同步的遠程調(diào)用，現(xiàn)在是通過 MQ 進行異步調(diào)用。如何保證消息沒有被重復(fù)消費？怎么處理消息丟失情況？那么保證消息傳遞的順序性？ -
一致性問題
A 系統(tǒng)處理完業(yè)務(wù)，通過 MQ 給B、C、D三個系統(tǒng)發(fā)消息數(shù)據(jù)，如果 B 系統(tǒng)、C 系統(tǒng)處理成功，D 系統(tǒng)處理失敗。如何保證消息數(shù)據(jù)處理的一致性？
四、常見的MQ組件
? 目前業(yè)界有很多的 MQ 產(chǎn)品，例如 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，也有直接使用 Redis 充當消息隊列的案例，而這些消息隊列產(chǎn)品，各有側(cè)重，在實際選型時，需要結(jié)合自身需求及 MQ 產(chǎn)品特征
五、什么是RabbitMQ
2007 年發(fā)布，是一個在 AMQP(高級消息隊列協(xié)議)基礎(chǔ)上完成的，可復(fù)用的企業(yè)消息系統(tǒng)，是當前最主流的消息中間件之一。
.
RabbitMQ是一個由erlang開發(fā)的AMQP（Advanced Message Queue 高級消息隊列協(xié)議 ）的開源實現(xiàn)，由于erlang 語言的高并發(fā)特性，性能較好，本質(zhì)是個隊列，F(xiàn)IFO 先入先出，里面存放的內(nèi)容是message
.
RabbitMQ是一個消息中間件:它接受并轉(zhuǎn)發(fā)消息。你可以把它當做一個快遞站點，當你要發(fā)送一個包裹時，你把你的包裹放到快遞站，快遞員最終會把你的快遞送到收件人那里，按照這種邏輯RabbitMQ是一個快遞站，一個快遞員幫你傳遞快件。RabbitMQ與快遞站的主要區(qū)別在于，它不處理快件而是接收，存儲和轉(zhuǎn)發(fā)消息數(shù)據(jù)。文章來源：http://www.zghlxwxcb.cn/news/detail-570972.html
六、RabbitMQ的原理–必須記住
名詞解釋:文章來源地址http://www.zghlxwxcb.cn/news/detail-570972.html
- Broker：接收和分發(fā)消息的應(yīng)用，RabbitMQ Server就是 Message Broker
- Connection：publisher／consumer 和 broker 之間的 TCP 連接
- Channel：如果每一次訪問 RabbitMQ 都建立一個 Connection，在消息量大的時候建立 TCP Connection的開銷將是巨大的，效率也較低。Channel 是在 connection 內(nèi)部建立的邏輯連接，如果應(yīng)用程序支持多線程，通常每個thread創(chuàng)建單獨的 channel 進行通訊，AMQP method 包含了channel id 幫助客戶端和message broker 識別 channel，所以 channel 之間是完全隔離的。Channel 作為輕量級的 Connection 極大減少了操作系統(tǒng)建立 TCP connection 的開銷.
- Exchange：message 到達 broker 的第一站，根據(jù)分發(fā)規(guī)則，匹配查詢表中的 routing key，分發(fā)消息到queue 中去。常用的類型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
- Queue：消息最終被送到這里等待 consumer 取走
- Binding：exchange 和 queue 之間的虛擬連接，binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查詢表中，用于 message 的分發(fā)依據(jù)
- Virtual host：出于多租戶和安全因素設(shè)計的，把 AMQP 的基本組件劃分到一個虛擬的分組中，類似于網(wǎng)絡(luò)中的 namespace 概念。當多個不同的用戶使用同一個 RabbitMQ server 提供的服務(wù)時，可以劃分出多個vhost，每個用戶在自己的 vhost 創(chuàng)建 exchange／queue 等
到了這里，關(guān)于消息中間件RabbitMQ詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
