consumer 是推还是拉？

Kafka 最初考虑的问题是，customer 应该从 brokes 拉取消息还是 brokers 将消

息推送到 consumer，也就是 pull 还 push。在这方面，Kafka 遵循了一种大部分

消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从

broker 拉取消息。

一些消息系统比如 Scribe 和 Apache Flume 采用了 push 模式，将消息推送到下

游的 consumer。这样做有好处也有坏处：由 broker 决定消息推送的速率，对于

不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以

最大的速率最快速的消费消息，但不幸的是，push 模式下，当 broker 推送的速

率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 还

是选取了传统的 pull 模式。

Pull 模式的另外一个好处是 consumer 可以自主决定是否批量的从 broker 拉取数

据。Push 模式必须在不知道下游 consumer 消费能力和消费策略的情况下决定是

立即推送每条消息还是缓存之后批量推送。如果为了避免 consumer 崩溃而采用

较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull 模式下，

consumer 就可以根据自己的消费能力去决定这些策略。

Pull 有个缺点是，如果 broker 没有可供消费的消息，将导致 consumer 不断在循

环中轮询，直到新消息到 t 达。为了避免这点，Kafka 有个参数可以让 consumer

阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可

以批量发送)。

巴特西