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

作者：陳睿|優知學院創始人

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

一、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.典型的秒殺活動、搶購、消息通訊、郵件發送、電話簡訊等都是典型的採用消息中間件的業務場景。

更多免費BAT面試經驗、架構進階、CTO進階 請關注獲取

推薦閱讀：

相關文章