我們在什麼情況下使用消息中間件。當我們遇到異步處理，流量削峯，應用解耦的情況下，使用消息中間件特別好。
市場上有很多消息中間件，我們主要考慮主流的，如ActiveMQ,RabbitMQ,Kafka,RocketMQ
1:選擇什麼樣的消息隊列
下面是性能比對錶
| 特性 | ActiveMq | RabbitMq | RocketMq | Kafka | ||
| 開發者語言 | java | erlang | java | scala | ||
| 單機吞吐量 | 萬級 | 萬級 | 10萬級 | 10萬級 | ||
| 時效性 | ms級 | us級 | ms級 | ms級以內 | ||
| 可用性 | 高（主從架構） | 高（主從架構） | 非常高（分佈式架構） | 非常高（分佈式架構） | ||
| 功能特性 |
成熟的產品，在很多公司得到應用； 有較多的文檔；各種協議支持較好 |
基於erlang開發，所以併發能力很強，性能極其好，延時很低;管理界面較豐富 |
|
|
綜合上面的材料得出以下兩點:
(1)中小型軟件公司，建議選RabbitMQ.一方面，erlang語言天生具備高併發的特性，而且他的管理界面用起來十分方便。正所謂，成也蕭何，敗也蕭何！他的弊端也在這裏，雖然RabbitMQ是開源的，然而國內有幾個能定製化開發erlang的程序員呢？所幸，RabbitMQ的社區十分活躍，可以解決開發過程中遇到的bug，這點對於中小型公司來說十分重要。不考慮rocketmq和kafka的原因是，一方面中小型軟件公司不如互聯網公司，數據量沒那麼大，選消息中間件，應首選功能比較完備的，所以kafka排除。不考慮rocketmq的原因是，rocketmq是阿里出品，如果阿里放棄維護rocketmq，中小型公司一般抽不出人來進行rocketmq的定製化開發，因此不推薦。
(2)大型軟件公司，根據具體使用在rocketMq和kafka之間二選一。一方面，大型軟件公司，具備足夠的資金搭建分佈式環境，也具備足夠大的數據量。針對rocketMQ,大型軟件公司也可以抽出人手對rocketMQ進行定製化開發，畢竟國內有能力改JAVA源碼的人，還是相當多的。至於kafka，根據業務場景選擇，如果有日誌採集功能，肯定是首選kafka了。具體該選哪個，看使用場景。
2：