为什么Kafka基于拉力而不是推基础？

Question

为什么Kafka基于拉力而不是推基础？我同意卡夫卡给了我经历过的高通量,但我没有看到卡夫卡吞吐量将如何往下走,如果它是基于推.关于基于推送的任何想法都会降低性能？

Answer 1

可伸缩性是我们设计此类系统(拉动与推动)时的主要驱动因素.Kafka非常具有可扩展性.Kafka的一个主要优点是,在不影响性能和不停机的情况下添加大量消费者非常容易.

Kafka可以处理来自生产商的每秒100k +的事件.由于Kafka消费者从主题中提取数据,因此不同的消费者可以以不同的速度消费消息.卡夫卡还支持不同的消费模式.您可以让一个消费者实时处理消息,另一个消费者以批处理模式处理消息.

另一个原因可能是Kafka不仅适用于像Hadoop这样的单一消费者.不同的消费者可以有不同的需求和能力.

基于拉动的系统存在一些缺陷,例如由于定期轮询而浪费资源.Kafka支持"长轮询"等待模式,直到实际数据通过以缓解这一缺点.

Answer 2

请参阅Kafka文档,其中详细说明了特定的设计决策:Push vs pull

支持拉动的主要观点是:

1. 在与多元化消费者打交道时,拉动更好(没有经纪人确定所有人的数据传输率);
2. 消费者可以更有效地控制个人消费的速度;
3. 更轻松,更优化的批处理实施.

基于拉取的系统(消费者在没有可用数据的情况下轮询数据)的缺点在一定程度上通过"长轮询"等待模式得到缓解,直到数据到达为止.

Answer 3

其他人则根据Kafka的文档提供了答案，但有时应以一定的盐作为产品文档，作为绝对的技术参考。例如：

• 许多基于推送的消息传递系统通常通过其会话管理原语来支持不同速率的消耗。当您要使用和挂起会话时，可以建立/恢复活动的应用程序层会话（例如，仅通过不以小于keepalive窗口的响应，而不是大于运行中的窗口的响应...或显式消息的形式）停止/暂停。例如，MQTT和AMQP都提供此功能（从90年代后期开始，在MQTT的情况下）。鉴于不需要采取任何行动来暂停消费（根据定义），并且在稳定的稳定状态下（无需请求）需要的流量更少，因此很难看到Kafka的基于拉动的模型的效率如何。
• 推式消息传递与拉式消息传递相比，一个重要的优势是，随着潜在活动主题的数量增加，请求流量不会扩大。如果您有一百万个潜在活动的主题，则必须对所有这些主题发出查询。这种关注在规模上变得尤为重要。
• 拉式消息传递相对于推式消息传递的关键优势是可重播性。这在很大程度上决定了下游系统是否可以提供处理方面的保证（例如，下游系统可能在这样做之前失败，并且必须重新启动，或者例如，无法以可恢复的方式写入消息）。
• 拉式消息传递与推式消息传递相比的另一个关键优势是缓冲区分配。消费过程可以显式请求可容纳在预分配缓冲区中的数据，而不必一遍又一遍地分配缓冲区。与查询缩放带来的推送消息相比，这可以弥补一些吞吐量损失（但不是很多）。但是，如果您的消息大小变化很大（例如，几KB->几百MB），则此处的影响是可以测量的。
• 提出拉式消息传递比推送消息传递具有结构可伸缩性优势是一个谬论。分区是通常用于在消息传递应用程序中提供规模的功能，而与消耗模型无关。在硬连线的本地集群上，有超过300M msgs / sec的推送消息系统运行良好... 125K msgs / sec甚至不能买入该节目。实际上，根据定义，拉式消息传递的生产率较差，并且像Kafka这样的系统通常最终会使用更多硬件来达到相同的性能水平。上面提到的好处通常会使它值得。我不知道有人使用Kafka在高频交易中进行消息传递，例如，微秒很重要。

可能有趣的是，在1990年代后期开发了各种推挽消息传递系统，作为优化吞吐量的一种方法。结果从未令人st舌，并且系统复杂性和其他因素常常超过了这种优化。我相信这是Jay关于在实际数据中心网络上的实际性能的总体观点，更不用说开放Internet之类的东西了。

Answer 4

Kafka 使用基于拉取的系统，允许用户请求消息。Pushing只是经纪人的额外工作。对于 Kafka，获取消息的责任由消费者承担。消费者可以决定他们想要以什么速率处理消息。

如果代理正在推送消息并且某些消费者已关闭，则代理将重试某些次来推送消息，直到他们决定不再推送。这会降低性能。想象一下向多个消费者推送消息的工作量。基于推送的方法适合低延迟消息传递。