消息隊列MQ與微消息隊列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拿就非常方便。

消息隊列的缺點

1. 添加MQ，如果MQ服務掛了，導致消息發送和接收就無法使用了。
2. 複雜度提高。

多種主流傳統消息隊列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是架在服務器與服務器之間。