消息中間件介紹、典型使用場景、以及使用原則

大型分佈式架構裏必定會涉及到消息中間件，今天先談談消息中間件。

經常使用的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ。

1、kafka

一、不徹底符合jms規範，注重吞吐量，相似udp 和 tcp

二、通常作大數據吞吐的管道，咱們如今的用途就是負責在各個idc之間通訊

三、量大對數據不是百分之百保證的，會有數據丟失，不是百分百送達（amq和rmq等有重發機制，而kafka沒有）；在吞吐量有提高 ，在這方面就得有犧牲， 因此kafka適合大數據量流轉， 好比日誌數據 好比用做統計的數據。

2、activeMQ ActiveMQ居於二者之間，相似於ZemoMQ，它能夠部署於代理模式和P2P模式。相似於RabbitMQ，它易於實現高級場景，並且只需付出低消耗。它被譽爲消息中間件的「瑞士軍刀」。

三：RocketMQ（阿里官方指定消息中間件） RocketMQ 是一款開源的分佈式消息系統，基於高可用分佈式集羣技術，提供低延時的、高可靠的消息發佈與訂閱服務。同時，普遍應用於多個領域，包括異步通訊解耦、企業解決方案、金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通訊、移動應用、手遊、視頻、物聯網、車聯網等。

消息中間件使用的典型場景優四個

1.典型的異步處理

2.應用解耦

3.流量削鋒

4.消息通信四個場景

好比：今日頭條的私信就是一個典型的消息通信場景，由於消息通信的數據不須要即便當即同步回來，不算是核心數據，能夠延時經過異步的消息發送，這樣能夠下降系統的負荷。

因此，咱們在架構設計的時候，有一個原則就是：消息原則上都是異步消息發送，除非涉及到交易的狀況才考慮數據即便同步，不然能異步的都採用異步消息設計。

再好比：流量削鋒的典型場景就有阿里的雙11秒殺、團購搶購活動等。

應用場景：秒殺活動，通常會由於流量過大，致使流量暴增，應用掛掉。爲解決這個問題，通常須要在應用前端加入消息隊列。

a、能夠控制活動的人數

b、能夠緩解短期內高流量壓垮應用

用戶的請求，服務器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面。

秒殺業務根據消息隊列中的請求信息，再作後續處理。

架構設計之中間件總結：

1.消息中間件的四個典型場景：典型的異步處理、應用解耦、流量削鋒、消息通信四個場景。

2.能異步就不要同步：能異步的消息原則都儘可能採用異步的方式。

3.若是消息性能要求高，用rocketMQ與kafka能夠更優，rocketMQ與kafka 比較就看技術選型了，各有利弊，看業務須要。

4.實現語言來看，RabbitMQ(阿里官方指定消息中間件)最高，緣由是它的實現語言是天生具有高併發高可用的erlang語言。綜合來看，RabbitMQ是首選。

5.典型的秒殺活動、搶購、消息通信、郵件發送、電話短信等都是典型的採用消息中間件的業務場景。