大多数文章描述了Kafka在读/写吞吐量方面比ActiveMQ等其他消息代理(MB)更好。每位矿工在偏移的帮助下理解读/写可以使其更快。但是我不清楚偏移量如何使它更快?
在阅读了Kafka架构之后,基于以下几点,我有了一些了解,但不清楚是什么使Kafka可扩展和高吞吐量:-
大概有了偏移量,客户端就知道需要读取的确切消息,这可能是使其具有较高性能的因素之一。
在其他MB的情况下,经纪人需要在消费者之间进行协调,以便仅将消息传递给消费者。但这仅适用于队列,而不适用于主题。然后,是什么使Kafka主题比其他MB主题更快。
Kafka提供分区以实现可伸缩性,但其他消息代理(MB)(例如ActiveMQ)也提供群集。那么Kafka如何适合大数据/高负载?
在其他MB中,我们可以有监听器。因此,一旦收到消息,代理将传递消息,但是如果是Kafka,我们需要进行轮询,这意味着代理/客户端双方都有更多负载?
Jay Kreps博客文章中有许多有关使Kafka与其他消息传递系统不同和更快的原因的详细信息
实际上,有很多差异可以使Kafka发挥出色的性能,包括但不限于:
Kafka 对于消息代理来说速度很快,这在很大程度上是为了营销。例如,IBM MessageSight 设备在 2013 年在一台机器上每秒处理 1300 万条消息,延迟为微秒。早在 Kreps 启动 Github 的一年前: https://www.zdnet.com/article/ibm-launches-messagesight-appliance-aimed-at-m2m/
卡夫卡对很多事情都有好处。真正的低延迟消息传递并不是其中之一。您绝对不能在任何纯粹以延迟为中心的环境中使用批量交付(例如一系列偏移量)。当事件到达时,如果您想要最低延迟,则必须立即尝试传递。这并不意味着等待几秒钟来批量读取事件块或承受请求每条消息的开销。如果您想将 Kafka 与普通的基于推送的代理进行比较,请尝试使用偏移量范围为 1(即:1 条消息)的 Kafka,您就会明白我的意思。
相反,我建议关注基于拉的流缓冲确实为您提供的东西:
就我个人而言,我认为这使得下游数据工程系统在面对故障时更容易构建,特别是因为您不必依赖它们内置的复制模型(如果它们有的话)。比如我很容易消费消息、丢失磁盘、恢复机器、重放丢失的数据。数据流成为其他系统可以同步的单一事实来源,这非常有用!
消息传递中没有免费的午餐,拉动和推送各有其优缺点。人们也尝试过推拉式消息传递,这可能不会令您感到惊讶,而且这也不是免费的午餐:)。
归档时间: |
|
查看次数: |
1519 次 |
最近记录: |