为什么卡夫卡是拉式的而不是推式的？

参考卡夫卡的文件，其中详细说明了具体的设计决策: 推和拉

支持拉力的主要观点有:

1. 在与多样化的消费者打交道时，拉动效果更好(没有经纪人决定所有人的数据传输速率) ;
2. 消费者可以更有效地控制个人消费率;
3. 更容易和更优化的批处理实现。

基于拉动的系统(消费者轮询数据而没有可用的数据)的缺点通过“长轮询”等待模式得到了一定程度的缓解，直到数据到达。

当我们设计这样的系统时，可伸缩性是主要的驱动因素(拉还是推)。卡夫卡是可扩展的。卡夫卡的一个关键好处是，它很容易增加大量的消费者，而不影响性能和没有停机时间。

卡夫卡可以以每秒10万以上的速度处理来自制片人的事件。因为卡夫卡的消费者从主题中提取数据，不同的消费者可以以不同的速度消费这些信息。卡夫卡还支持不同的消费模式。您可以让一个使用者实时处理消息，让另一个使用者以批处理模式处理消息。

另一个原因可能是卡夫卡不仅仅是为像 Hadoop 这样的单一消费者设计的。不同的消费者可能有不同的需求和能力。

基于拉动的系统有一些缺陷，比如由于定期轮询而造成的资源浪费。卡夫卡支持“长轮询”等待模式，直到真实数据出现，以减轻这一缺点。

其他人则根据卡夫卡的文档提供了答案，但有时产品文档作为绝对的技术参考应该持保留态度。例如:

• 许多基于推送的消息传递系统支持 不同的速率，通常通过它们的会话管理原语。 建立/恢复活动应用程序层会话 要使用和暂停会话(例如: 当你需要的时候，响应小于保留窗口，大于飞行窗口... 或者用一个明确的消息) 例如，MQTT 和 AMQP 都提供了这种功能 (在 MQTT 的例子中，从90年代末开始) 需要暂停消费(根据定义) ，并减少流量 在稳定状态下(没有要求) ，很难 看看卡夫卡的拉式模型是如何更有效率的。
• 推送式消息传递与拉式消息传递的一个关键优势是 没有请求流量作为潜在的数量进行扩展 活跃的话题增加。如果你有一百万个潜在的活跃 主题，则必须对所有这些主题发出查询 关注在规模上变得尤为重要。
• 拉式消息传递相对于推式消息传递的关键优势是 可重放性。这在很大程度上影响了下游系统是否能够提供处理周围的保证(例如，它们可能在这样做之前失败，并且必须重新启动，或者例如，不能可恢复地写消息)。
• 拉式消息传递与推式消息传递的另一个关键优势是 缓冲区分配缓冲区分配。消费进程可以显式地请求预分配缓冲区中所能容纳的尽可能多的数据，而不必一遍又一遍地分配缓冲区。与查询缩放的推送消息相比，这可以收回一些 Goodput 损失(但不是很多)。然而，如果您的消息大小差异很大(例如几 KB-> 几百 MB) ，这里的影响是可以衡量的。
• 认为拉式消息传递比推式消息传递具有结构性可伸缩性优势是错误的。分区通常用于在消息传递应用程序中提供伸缩性，而不管消费模型是什么。有推送消息系统运行超过300毫秒/秒的硬有线本地集群... 125K 毫秒/秒甚至不买入场券。事实上，拉式消息传递按定义具有 下等货良好输入，像 Kafka 这样的系统通常最终使用 更多硬件来达到相同的性能水平。上面提到的好处往往使得它的成本物有所值。我不知道有人使用卡夫卡在高频交易信息，例如，微秒问题。

值得注意的是，各种推拉式消息传递系统是在20世纪90年代后期开发的，作为一种优化商品输入的方法。结果从来没有惊人的，系统的复杂性和其他因素往往超过这种优化。我相信这是 Jay 关于真实数据中心网络的实际性能的总体观点，更不用说像开放互联网这样的东西了。

Pushing只是经纪人的额外工作。对于卡夫卡，获取消息的责任在于消费者。消费者可以决定以什么速率处理消息。

如果一个代理正在推送消息，并且一些消费者处于宕机状态，那么代理将重试某些时间来推送消息，直到他们决定不再推送消息为止。这会降低性能。想象一下将消息推送到多个消费者的工作负载。