文章目錄

• • 參考文章
  • 什么是消息隊列，什么是RPC
  • 為什么要使用MQ消息隊列
  • • • 1. 解耦（可用性）
      • 2. 流量削峰
      • 3. 數據分發
  • 消息隊列的缺點
  • 多種主流傳統消息隊列MQ對比
  • 傳統消息隊列RocketMQ和微消息隊列MQTT對比

參考文章

https://www.jianshu.com/p/15081799d66b
非常好的描述消息隊列應用場景文章1
非常好的描述消息隊列應用場景文章2
https://www.cnblogs.com/mokafamily/p/9061322.html

什么是消息隊列，什么是RPC

在分布式服務器和服務器通信時，RPC可以解決問題。
而我們使用消息隊列一個主要優勢就是，增加消息的堆積能力，也就是類似于Java線程池實現基本原理就是消息中間件。當然這也增加了維護成本。和復雜度。

所以現在一般都不使用RPC

為什么要使用MQ消息隊列

1. 解耦（可用性）

不同服務器系統之間使用RPC調用，會使系統之間的耦合性非常高。
當一個系統掛了另一個系統就無法使用。可用性降低。

訂單系統把消息發送給MQ服務，然后不同的系統再進行消費。當一個系統掛了也不要緊，等恢復的時候再去MQ中拿消息，這樣系統的可用性就大大提高了。也就是耦合性沒那么高。一個系統不那么依賴于另一個系統。
而使用MQ我們則可以降低該耦合性。

2. 流量削峰

場景1: 當用戶量瞬間陡增，秒殺處理系統可以處理這么多的請求，但是當發送給通知系統這樣可能壓垮數據庫。

舉個栗子，秒殺業務：

上游發起下單操作。（比如機票系統，火車票系統，等都是上游，只發起請求操作。）

下游完成秒殺業務邏輯（庫存檢查，庫存凍結，余額檢查，余額凍結，訂單生成，余額扣減，庫存扣減，生成流水，余額解凍，庫存解凍）

上游下單業務簡單，每秒發起了10000個請求，下游秒殺業務復雜，每秒只能處理2000個請求，很有可能上游不限速的下單，導致下游系統被壓垮，引發雪崩。

解決：我們使用MQ在中間，這樣A系統就每次從MQ拉取我能承受的2K個請求。雖然可能會有一定延遲，但比系統掛了強。


場景2: 也就是我們的需求場景，用戶服務器系統，發送大量請求調用我們醫療服務器系統接口。我們系統可能無法承受如此大請求量。那么我們在系統和系統之間加一個MQ服務。進行流量削峰。在這里也考慮到經濟目的，因為我們不可能光為了峰值請求而更換硬件和軟件，畢竟流量峰值只是短暫的。

3. 數據分發

比如A系統要分發消息給多個系統，那么如果說他每次都發送給B系統C系統D系統，當多個系統更改需求的時候都需要通知A系統，這樣對A系統來說很麻煩。使用MQ直接把消息發送給MQ。誰需要消息誰就去MQ拿就非常方便。

消息隊列的缺點

添加MQ，如果MQ服務掛了，導致消息發送和接收就無法使用了。

復雜度提高。

多種主流傳統消息隊列MQ對比

現在使用比較多的是RabbitMQ和Rocket MQ
RabbitMQ是國外的RocketMQ是阿里的。
RocketMQ的支持比較多，可擴展和可用性強。
RabbitMQ是erlang編寫的，性能非常好，時效性非常強，但是可擴展性不是很強。

傳統消息隊列RocketMQ和微消息隊列MQTT對比

傳統的消息中間件，例如消息隊列 RocketMQ、消息隊列 RabbitMQ kafka 等都是面向微服務大數據等領域，負責消息的存儲和轉發，消息的生產者和消費者都是服務端應用。

而移動互聯網和 IoT 領域則有所不同，這類場景更側重于多語言多平臺的海量設備接入，消息的生產和消費過程的業務屬性很突出，傳統的消息中間件并不適合這些領域。

微消息隊列 MQTT 在設計上是一個面向移動互聯網和 IoT 領域的無狀態網關，只關心海量移動端設備的接入、管理和消息傳輸

http://www.360doc.com/content/19/0514/20/835902_835720104.shtml


基于上圖我們可以大概了解，MQTT是架在服務端和客戶端之間他可以分發給多個客戶端。而RocketMQ是架在服務器與服務器之間。

總結

以上是生活随笔為你收集整理的消息队列MQ与微消息队列MQTT的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。