Kafka是最初由Linkedin公司開發，是壹個分布式、支持分區的(partition)、多副本的(replica)，基於zookeeper協調的分布式消息系統，它的最大的特性就是可以實時的處理大量數據以滿足各種需求場景：比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎，web/nginx日誌、訪問日誌，消息服務等等，用scala語言編寫，Linkedin於2010年貢獻給了Apache基金會並成為頂級開源 項目。
JMS(Java Message Service)是Java提供的壹套技術規範
用來異構系統 集成通信，緩解系統瓶頸，提高系統的伸縮性增強系統用戶體驗，使得系統模塊化和組件化變得可行並更加靈活
(1) 點對點模式(壹對壹，消費者主動拉取數據，消息收到後消息清除)
點對點模型通常是壹個基於拉取或者輪詢的消息傳送模型，這種模型從隊列中請求信息，而不是將消息推送到客戶端。這個模型的特點是發送到隊列的消息被壹個且只有壹個接收者接收處理，即使有多個消息監聽者也是如此。
(2) 發布/訂閱模式(壹對多，數據生產後，推送給所有訂閱者)
發布訂閱模型則是壹個基於推送的消息傳送模型。發布訂閱模型可以有多種不同的訂閱者，臨時訂閱者只在主動監聽主題時才接收消息，而持久訂閱者則監聽主題的所有消息，即使當前訂閱者不可用，處於離線狀態。
kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作。
kafka集群支持熱擴展
消息被持久化到本地磁盤，並且支持數據備份防止數據丟失
允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）
支持數千個客戶端同時讀寫
壹個公司可以用Kafka可以收集各種服務的log，通過kafka以統壹接口服務的方式開放給各種consumer，例如hadoop、Hbase、Solr等。
解耦和生產者和消費者、緩存消息等。
Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發布到kafka的topic中，然後訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到hadoop、數據倉庫中做離線分析和挖掘。
Kafka也經常用來記錄運營監控數據。包括收集各種分布式應用的數據，生產各種操作的集中反饋，比如報警和報告。
比如spark streaming和storm
Kafka每個主題的多個分區日誌分布式地存儲在Kafka集群上，同時為了故障容錯，每個分區都會以副本的方式復制到多個消息代理節點上。其中壹個節點會作為主副本(Leader)，其他節點作為備份副本(Follower，也叫作從副本)。主副本會負責所有的客戶端讀寫操作，備份副本僅僅從主副本同步數據。當主副本出現故障時，備份副本中的壹個副本會被選擇為新的主副本。因為每個分區的副本中只有主副本接受讀寫，所以每個服務器端都會作為某些分區的主副本，以及另外壹些分區的備份副本，這樣Kafka集群的所有服務端整體上對客戶端是負載均衡的。
Kafka的生產者和消費者相對於服務器端而言都是客戶端。
Kafka生產者客戶端發布消息到服務端的指定主題，會指定消息所屬的分區。生產者發布消息時根據消息是否有鍵，采用不同的分區策略。消息沒有鍵時，通過輪詢方式進行客戶端負載均衡；消息有鍵時，根據分區語義（例如hash）確保相同鍵的消息總是發送到同壹分區。
Kafka的消費者通過訂閱主題來消費消息，並且每個消費者都會設置壹個消費組名稱。因為生產者發布到主題的每壹條消息都只會發送給消費者組的壹個消費者。所以，如果要實現傳統消息系統的“隊列”模型，可以讓每個消費者都擁有相同的消費組名稱，這樣消息就會負責均衡到所有的消費者；如果要實現“發布-訂閱”模型，則每個消費者的消費者組名稱都不相同，這樣每條消息就會廣播給所有的消費者。
分區是消費者現場模型的最小並行單位。如下圖（圖1）所示，生產者發布消息到壹臺服務器的3個分區時，只有壹個消費者消費所有的3個分區。在下圖（圖2）中，3個分區分布在3臺服務器上，同時有3個消費者分別消費不同的分區。假設每個服務器的吞吐量時300MB，在下圖（圖1）中分攤到每個分區只有100MB，而在下圖（圖2）中，集群整體的吞吐量有900MB。可以看到，增加服務器節點會提升集群的性能，增加消費者數量會提升處理性能。
同壹個消費組下多個消費者互相協調消費工作，Kafka會將所有的分區平均地分配給所有的消費者實例，這樣每個消費者都可以分配到數量均等的分區。Kafka的消費組管理協議會動態地維護消費組的成員列表，當壹個新消費者加入消費者組，或者有消費者離開消費組，都會觸發再平衡操作。
Kafka的消費者消費消息時，只保證在壹個分區內的消息的完全有序性，並不保證同壹個主題匯中多個分區的消息順序。而且，消費者讀取壹個分區消息的順序和生產者寫入到這個分區的順序是壹致的。比如，生產者寫入“hello”和“Kafka”兩條消息到分區P1，則消費者讀取到的順序也壹定是“hello”和“Kafka”。如果業務上需要保證所有消息完全壹致，只能通過設置壹個分區完成，但這種做法的缺點是最多只能有壹個消費者進行消費。壹般來說，只需要保證每個分區的有序性，再對消息假設鍵來保證相同鍵的所有消息落入同壹分區，就可以滿足絕大多數的應用。