Kafka 最初考慮的問題是，customer 應(yīng)該從 brokes 拉取消息還是 brokers 將消息推送到

consumer，也就是 pull 還 push。

在這方面，Kafka 遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計：

producer 將消息推送到 broker，consumer 從 broker 拉取消息

一些消息系統(tǒng)比如 Scribe 和 ApacheFlume 采用了 push 模式，將消息推送到下游的 consumer。

這樣做有好處也有壞處：

由 broker 決定消息推送的速率，對于不同消費速率的 consumer 就不太好處理了。消息系統(tǒng)都致力于讓 consumer 以最大的速率最快速的消費消息，但不幸的是，push 模式下，當 broker 推送的速率遠大于 consumer 消費的速率時， consumer 恐怕就要崩潰了。

最終 Kafka 還是選取了傳統(tǒng)的 pull 模式

Pull 模式的另外一個好處是 consumer 可以自主決定是否批量的從 broker 拉取數(shù)據(jù)。Push 模式必須在不知道下游 consumer 消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免 consumer 崩潰而采用較低的推送速率，將可能導致一次只推送較少的消息而造成浪費。

Pull 模式下，consumer 就可以根據(jù)自己的消費能力去決定這些策略

Pull 有個缺點是，如果 broker 沒有可供消費的消息，將導致 consumer 不斷在循環(huán)中輪詢，

直到新消息到 t 達。為了避免這點，Kafka 有個參數(shù)可以讓 consumer 阻塞知道新消息到達