轉自：https://www.zhihu.com/question/272186518

這是兩種截然不同的mq。

Active MQ被稱為“傳統”mq。所謂“傳統”是指，

1. 他要支援一些標準介面，比如AMQP, STOMP等
2. 需要維護consumer的狀態。即當前consumer讀到哪個資料了，是active mq來維護的。
3. active mq最早用來做企業級別的系統整合。要支援所謂的“企業級佇列模式“，但請原諒我搞到最後也沒理解這個企業級到底怎麼企業級了，也許現在的大多數企業早已不像10多年前那樣設計系統了？
4. active mq因為支援XA協議，所以可以和JDBC一起實現2PC分散式事務，但我基本沒見過有人這麼用，大概是因為太慢和太難維護的原因。
5. active mq支援對事物處理的commit（自動+手動），但是如果你理解分散式一致性的話就能明白單一系統能夠commit還是無法滿足一致性的要求

其實我看到過有人用它，完全是因為他是java這個圈子裡第一個廣泛被使用的mq（之後又有rabbit mq），是一種習慣。

而Kakfa一開始被設計就是以高吞吐+高效能+HA來實現的。我的壓測顯示Kafka的吞吐量大概高於active mq兩個數量級。即使Kafka配置了全同步的複製，也會比Active MQ高5～6倍。

Kafka的核心設計是append log file。即不斷追加寫log檔案來實現訊息資料的寫入（對比一下，active mq的內部更偏向一個傳統資料庫，不過active mq最近的版本開始用level db）。磁碟追加寫的效能要遠高於隨機寫。Kafka允許consumer自己維護自己讀取到了的位置，還允許隨時調整這個位置做“message replay”。

Kafka圍繞topic和partition的模型解決了message的分發和HA的問題，並且能夠通過配置來支援全非同步，半同步，全同步的複製。

最近Kafka提供了一個新的Stream API，順便還支援了事務（但限制在資料處理這個步驟）

總體來講Kafka特別適合的場景是實時資料分析，log分析等場景。但是如果用來做業務事件的分發，也非常適合。

如果業務場景壓力不大，又比較傳統，需要那些老的message協議，用Active MQ完全夠用，但同時也可以考慮一下同類的Rabbit MQ；但是如果吞吐量的要求很大，那麼Kafka幾乎可能是自研之外，非常理想的選擇了。。

----- 更新一下 ----

回答一下Kafka的缺點和不適合的場景。

說實話，我並沒有發現Kafka本身有什麼明顯的短板。如果倒退幾年，Kafka 0.7，0.8版本的年代，也許可以說他缺一些功能，比如認證，SSL端端加密，比較好用的管理運維工具等等；這個比起Active MQ 10+年曆史上積累的工具差很多。但是Kafka的最新版本已經補上了這些問題，各種功能工具都逐漸完備了。

如果非得說Kafka有啥缺點，可能就是運維略複雜。你可能需要安裝很多元件，還要調整一些OS系統引數來對Kafka進行調優。一些好處（比如message replay）需要額外的開發。一些一致性上的把控，kafka選擇把底層的一些細節暴露出來，由整合的開發者來把控。不能做到拆箱即用。對於小團隊，這樣的運維成本有些高。但對於一個高效能系統，這些工作是天經地義的事情。

另外Kafka並不支援Java的那些“標準messaging”協議，所以如果應用場景一定要用到這些標準，那麼只能和Kafka說拜拜。（但這裡一定要吐一下槽，那些標準協議除了一層層的抽象，根本就沒能解決messaging系統裡的很多實際的問題。但是Kafka的確解決了那些問題，比如HA，客戶端自動重連，自動去重等）

============================================================================

目前我們公司同時在用amq和kafka兩種產品。但是也定下了以kafka為主，amq為輔的路線。

就像第一個回答所說，amq是一個專門針對訊息場景的mq，而kafka現在的發展趨勢主要是流資料處理平臺。

amq的優勢是功能全，安裝簡單，需要的資源比kafka少，兩臺amq就能滿足服務高可用。壞處是效能較低，但是這也是看場景的。曾經嘗試過將amq調整成純記憶體模式，單臺4C8G的伺服器配4GJVM效能就能達到6w TPS。此外amq目前版本是5.15，而在5.11前的版本支援jdk1.6，對一些仍在使用jdk1.6的應用做分散式遷移時仍然可以使用主要功能。

還有個主要優勢就是協議支援得太全了，包括mqtt,amqp,stormp全都支援，簡直萬能。

kafka是一個性能怪獸，簡單配置就輕鬆可以達到10w TPS。而且不像市面上其它mq一樣以broker為維度做高可用，而是以topic和partition，這樣就不會有備機特別閒的問題。但是kafka的主要問題有以下幾個：

1. 對zk的依賴，zk一直有超半數節點宕機就宕的問題，這個問題導致了zk的部署必須非常小心。

2. 對訊息服務功能方面的支援不如其它mq那麼好，比如協議支援的不足，訊息延遲投遞功能的缺失，訊息選擇器功能的不足等等。消費者橫向擴容更是需要人工增加partition數量。

3. 同等資源條件下和amq比較，能建立的topic數量遠低於amq。這也制約了大量佇列的場景。

之前和別的公司交流過，他們為了讓kafka能滿足他們對訊息服務的需求，甚至在每一個kafka元件前設定了一個自己寫的不同功能的前置伺服器。比如消費者和broker之間，生產者和broker之間，broker和zk之間等等

非利益相關，如果需要考慮和kafka類似的專注於訊息服務領域的產品，可以看看阿里開源的RocketMQ，更側重於mq領域。