定義:kafka是一個分佈式,基於zookeeper協調的發佈/訂閱模式的消息系統,本質是一個MQ(消息隊列Message Queue),主要用於大數據實時處理領域。服務器
目的:解耦、削峯、異步、緩衝(生產大於消費的狀況)微信
日誌保留(retention):咱們能夠配置主題的消息保留策略,譬如只保留一段時間的日誌或者只保留特定大小的日誌。當超過這些限制時,老的消息會被刪除。咱們也能夠針對某個主題單獨設置消息過時策略,這樣對於不一樣應用能夠實現個性化。併發
PS:消息隊列中的消息不是永久存的,會定時刪除,自動刪除的時間能夠配置。異步
最大的特性就是能夠實時的處理大量數據以知足各類需求場景。分佈式
如上圖所示,點對點模式一般是基於拉取或者輪詢的消息傳送模型,這個模型的特色是發送到隊列的消息被一個且只有一個消費者進行處理。生產者將消息放入消息隊列後,由消費者主動的去拉取消息進行消費。當一個消費者消費了隊列中的某條數據以後,該條數據則從消息隊列中刪除。性能
優勢:拉取消息的頻率能夠由本身控制。大數據
存在缺陷:消費者端沒法感知消息隊列是否有消息須要消費,因此在消費者端須要額外的線程去監控。spa
如上圖所示,發佈訂閱模式是一個基於消息送的消息傳送模型,該模型能夠有多種不一樣的訂閱者。生產者將消息放入消息隊列後,隊列會將消息推送給訂閱過該類消息的消費者(相似微信公衆號)。因爲是消費者被動接收推送,因此無需感知消息隊列是否有待消費的消息!可是consumer一、consumer二、consumer3因爲機器性能不同,因此處理消息的能力也會不同,而消息隊列卻沒法感知消費者消費的速度!因此推送的速度成了發佈訂閱模模式的一個問題!假設三個消費者處理速度分別是8M/s、5M/s、2M/s,若是隊列推送的速度爲5M/s,則consumer3沒法承受!若是隊列推送的速度爲2M/s,則consumer一、consumer2會出現資源的極大浪費!.net
優勢:消費者無需感知消息隊列是否有待消費的消息。線程
存在缺陷:服務者沒法感知消費者機器的性能,容易形成接收溢出或主機資源浪費。
Kafka 是一種分佈式的,基於發佈 / 訂閱的消息系統。主要設計目標以下:
Producer:Producer即生產者,消息的產生者,是消息的入口。
kafka cluster:kafka集羣
Broker(kafka實例,可看作kafka主機):每一個服務器上有一個或多個kafka的實例,咱們姑且認爲每一個broker對應一臺服務器。每一個kafka集羣內的broker都有一個不重複的編號,如圖中的broker-0、broker-1等……
Topic(消息主題,即分類):能夠理解爲消息的分類,kafka的數據就保存在topic。在每一個broker上均可以建立多個topic。
Partition(分區):每一個topic能夠有多個分區,分區的做用是作負載,提升kafka的吞吐量(併發)。同一個topic在不一樣的分區的數據是不重複的,partition的表現形式就是一個一個的文件夾!
Replication(副本):每個分區都有多個副本,副本的做用是作備胎。當主分區(Leader)故障的時候會選擇一個備胎(Follower)上位,成爲Leader。在kafka中默認副本的最大數量是10個,且副本的數量不能大於Broker的數量,follower和leader絕對是在不一樣的機器,同一機器對同一個分區也只可能存放一個副本(包括本身)。
Message(消息內容):每一條發送的消息主體。
Consumer:消費者,即消息的消費方,是消息的出口。
Consumer Group:咱們能夠將多個消費組組成一個消費者組,在kafka的設計中同一個分區的數據只能被消費者組中的某一個消費者消費(不一樣組的消費者能夠消費同一個分區的數據)。同一個消費者組的消費者能夠消費同一個topic的不一樣分區的數據,這也是爲了提升kafka的吞吐量!
Zookeeper:kafka集羣依賴zookeeper來保存集羣的的元信息,來保證系統的可用性。
kafka集羣的正常使用須要依賴zookeeper,能夠幫kafka集羣存儲一些信息。
zookeeper也能夠保存消費者的消費信息,目的是消費者掛了重啓後,能夠接着上次的消費位置繼續消費(消費者內存中也會有一份備份,沒掛的時候直接取內存)。
參考資料: