Producer主動的經過push將消息發佈到Broker上,Consumer經過Pull的的方式從Broker消息消息。算法
經過Push的方式因爲是一有消息就推到Broker,因此極大的保證了消息實時性,可是在某些狀況下,可能因爲Consumer網絡,或是其餘緣由卻是消費速度低,此時就可能會致使Consumer堆積大量的消息,甚至在極端狀況下會壓垮Consumer.網絡
經過Pull拉取消息保證了Consumer可以按本身實際處理能力來拉取相應的消息,而且Broker的實現也相對簡單,可是也會出如今消息處理能力很低的狀況下形成消息的實時性太低。oop
kafka提供了High Level Consumer和High Level Consume兩種方式的API。設計
不少應用場景下,客戶程序只是但願從Kafka順序讀取並處理數據,而不太關心具體的offset。它同時也但願提供一些語義,例如同一條消息只被某一個Consumer消費(單播)或被全部Consumer消費(廣播),Kafka High Level API提供了一個從Kafka消費數據的高層抽象,從而屏蔽掉其中的細節,並提供豐富的語義。orm
在Kafka中,High Level Consumer將從某個Partition讀取的最後一條消息的offset存於Zookeeper中(從0.8.2開始同時支持將offset存於Zookeeper中和專用的Kafka Topic中)。這個offset基於客戶程序提供給Kafka的名字來保存,這個名字被稱爲Consumer Group,Consumer Group是整個Kafka集羣全局惟一的,而非針對某個Topic的。每一個High Level Consumer實例都屬於一Consumer Group,若不指定則屬於默認的Group。在消息被消費以後,消息並不會當即被刪除,只是相應的offset加一,若以可能Consumer中的offset將會跟消息的數據同樣多,blog
在High Level Consumer下因爲存在了關聯關係(Group ),因此消息刪除也將再也不是到必定時間或消息條數達到某個值就刪除,而是經過壓縮的方式,保留最新的key的value的方式。具體示例以下:排序
這樣就保證了消息與offset之間仍然是正確的對應關係。事務
對於每條消息,在同一個Consumer Gourp裏都只會被一個Consumer消費,不一樣的Cosumer Group能夠消費同一條消息。kafka
以下:it
Kafka的設計理念之一就是同時提供對離線批處理和在線流處理的支持。能夠同時使用Hadoop系統進行離線批處理,Storm或它流處理系統進行流處理。也可以使用Kafka的Mirror Maker將消息從一個數據中心鏡像到另外一個數據中心。
如圖:
Consumer的Rebalance(平衡策略)
High Level Consumer啓動時將其ID註冊到其Consumer Group下,在Zookeeper上的路徑爲/consumers/[consumer group]/ids/[consumer id],在/consumers/[consumer group]/ids上註冊Watch,在/brokers/ids上註冊Watch,若是Consumer經過Topic Filter建立消息流,則它會同時在/brokers/topics上也建立Watch,強制本身在其Consumer Group內啓動Rebalance流程
Rebalance算法
1. 將目標Topic下的全部Partirtion排序,存於PT
2. 對某Consumer Group下全部Consumer排序,存於CG,第i個Consumer記爲Ci
3. N=size(PT)/size(CG) ,向上取整
4. 解除Ci對原來分配的Partition的消費權(i從0開始)
5. 將第i∗N 到(i+1)∗N−1個Partition分配給Ci
Rebalance算法也存在以下缺點:
1. Herd Effect: 任何Broker或者Consumer的增減都會觸發全部的Consumer的Rebalance
2. Split Brain: 每一個Consumer分別單獨經過Zookeeper判斷哪些Broker和Consumer宕機,同時Consumer在同一時刻從Zookeeper「看」到的View可能不徹底同樣,這是由Zookeeper的特性決定的。
3. 調整結果不可控全部Consumer分別進行Rebalance,彼此不知道對應的Rebalance是否成功
使用Low Level Consumer (Simple Consumer)的主要緣由是,用戶但願比Consumer Group更好的控制數據的消費,如:
1. 同一條消息讀屢次,方便Replay
2. 只消費某個Topic的部分Partition
3. 管理事務,從而確保每條消息被處理一次(Exactly once)
與High Level Consumer相對,Low Level Consumer要求用戶作大量的額外工做
1. 在應用程序中跟蹤處理offset,並決定下一條消費哪條消息
2. 獲知每一個Partition的Leader
3. 處理Leader的變化
5. 處理多Consumer的協做