一、kafka
1、不完全符合jms規範，注重吞吐量，類似udp 和 tcp
2、一般做大數據吞吐的管道 我們現在的用途就是負責在各個idc之間通信
3、量大對數據不是百分之百保證的，會有數據丟失，不是百分百送達（amq和rmq等有重發機制，而kafka沒有）；在吞吐量有提升 ，在這方面就得有犧牲， 所以kafka適合大數據量流轉， 比如日誌數據 比如用作統計的數據。
二、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.典型的秒殺活動、搶購、消息通訊、郵件發送、電話短信等都是典型的採用消息中間件的業務場景。