其他人则根据Kafka的文档提供了答案，但有时产品文档应该作为绝对的技术参考。例如：
许多基于推送的消息传递系统通常通过会话管理原语以不同的速率支持使用。当您希望使用和挂起会话时（例如，在小于keepalive窗口和大于飞行中窗口时不响应…或使用显式消息），可以建立/恢复活动的应用程序层会话。例如，mqtt和amqp都提供了这种功能（在mqtt的情况下，自90年代末以来）。考虑到不需要采取任何措施来暂停消费（顾名思义），并且在稳定状态下（无请求）所需的通信量较少，很难看出kafka基于pull的模型如何更有效。
推式消息传递与拉式消息传递的一个关键优势是，没有请求流量可以随着潜在活动主题数量的增加而扩展。如果你有一百万个潜在的活动主题，你必须对所有这些主题发出查询。这个问题在规模上变得尤为重要。
拉式消息传递与推式消息传递的关键优势是可重放性。这在很大程度上影响了下游系统是否能够提供处理方面的保证（例如，它们可能在处理之前失败，必须重新启动，或者无法以可恢复的方式写入消息）。
拉式消息传递与推式消息传递的另一个关键优势是缓冲区分配。消费进程可以显式地请求预分配缓冲区中容纳的尽可能多的数据，而不必一次又一次地分配缓冲区。这弥补了查询伸缩带来的与推送消息传递相比的一些goodput损失（但不多）。但是，如果您的消息大小变化很大（例如，几kb->几百mb），那么这里的影响是可以测量的。
认为拉式消息传递比推式消息传递具有结构性可伸缩性优势是错误的。分区通常用于在消息传递应用程序中提供可伸缩性，而与使用模型无关。在有线本地集群上，推送消息系统的运行速度超过3亿msgs/秒……12.5万msgs/秒甚至不足以购买展会入场券。事实上，从定义上讲，拉式消息传递具有较差的性能，而像kafka这样的系统通常会使用更多的硬件来达到相同的性能水平。上面提到的好处往往使它值得付出代价。我不知道有人在高频交易中使用Kafka来传递信息，例如，在这种情况下，微秒很重要。
值得注意的是，各种推拉式消息传递系统是在20世纪90年代末开发的，作为优化goodput的一种方法。结果从来都不是惊人的，系统复杂性和其他因素往往超过了这种优化。我相信这是jay关于实际数据中心网络性能的观点，更不用说开放互联网了。

可伸缩性是我们设计此类系统（pull vs push）的主要驱动因素。Kafka是非常可扩展的。Kafka的主要优点之一是，它很容易添加大量的消费者，而不会影响性能和停机时间。
Kafka能够以每秒10万以上的速度处理来自制作人的事件。因为kafka的消费者从主题中提取数据，所以不同的消费者可以以不同的速度消费消息。Kafka还支持不同的消费模式。您可以让一个使用者实时处理消息，另一个使用者以批处理模式处理消息。
另一个原因可能是kafka不仅仅是为hadoop这样的单一用户设计的。不同的消费者可以有不同的需求和能力。
基于pull的系统有一些缺陷，比如由于定期轮询而造成的资源浪费。kafka支持“长轮询”等待模式，直到真正的数据通过，以缓解这一缺点。

请参阅Kafka文件，其中详细说明了特定的设计决策：推与拉
有利于拉动的要点有：
pull更适合于处理多样化的消费者（没有经纪人决定所有人的数据传输速率）；
消费者可以更有效地控制个人消费率；
更简单、更优化的批处理实现。
基于pull的系统（消费者在没有可用数据的情况下轮询数据）的缺点通过在数据到达之前的“长轮询”等待模式得到了一定程度的缓解。