activemq和kafka有什麼區別？
這是兩種截然不同的mq。Active MQ被稱為“傳統”mq。所謂“傳統”是指，他要支援一些標準介面，比如AMQP, STOMP等需要維護consumer的狀態。即當前consumer讀到哪個資料了，是active mq來維護的。active mq最早用來做企業級別的系統整合。要支援所謂的“企業級佇列模式“，但請原諒我搞到最後也沒理解這個企業級到底怎麼企業級了，也許現在的大多數企業早已不像10多年前那樣設計系統了？active mq因為支援XA協議，所以可以和JDBC一起實現2PC分散式事務，但我基本沒見過有人這麼用，大概是因為太慢和太難維護的原因。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，客戶端自動重連，自動去重等）