文章 标签 分类

Contents

Why Kafka

spike014
   1386 words   3 minutes 

背景

半年多前，初出茅庐的我接触到消息代理。我是这么做的：

首先，搜一下有哪些著名的开源消息代理组件：

  • Kafka

  • RabbitMQ

  • Redis 的 Pub/Sub 也可以实现消息广播传递。

再看下他们之间的对比，主要来自各种官方文档，网络上的文章（medium 等），之后做出选择。

但是很显然，现在回过头看，调研并没有深度，并没有非常合理地梳理好他们之间的差异，搞清楚自己要什么，不要什么，只需要一个消息处理组件来保证消息传递的准确性。但是其实他们之间还有很多差异性，可以玩出很多花样，提供很好的扩展性等。

网络上关于他们之间的比较有很多，但是我认为很多都是抄来抄去，并无新意。同时，以上的组件，他们并不会告诉你，自身软件不适合哪些场景，都是一大堆的 feature 介绍… 最后匆匆下结论，点击到手，开摆。读完其实还是云里雾里。

最近，笔者在阅读 《DDIA》中 Chapter 11: Stream Processing # Transmitting Event Streams 的时候才又有了新的感悟。感叹 Kafka 功能，扩展性的强大，同时对它适合的场景，以及为什么其他消息组件无法替代他有了新的思考，因此写下这篇。

对比

是否可重复消费消息

首先指出一个很多文章没有指出的差异：

《DDIA》:

  • AMQP/JMS 风格的消息代理

    代理将单条消息分配给消费者，消费者在成功处理单条消息后确认消息。消息被确认后从代理中删除。这种方法适合作为一种异步形式的 RPC，例如在任务队列中，消息处理的确切顺序并不重要，而且消息在处理完之后，不需要回头重新读取旧消息。

  • 基于日志的消息代理

    代理将一个分区中的所有消息分配给同一个消费者节点，并始终以相同的顺序传递消息。并行是通过分区实现的，消费者通过存档最近处理消息的偏移量来跟踪工作进度。消息代理将消息保留在磁盘上，因此如有必要的话，可以回跳并重新读取旧消息。

这里可以得出一个明显的差异，Kafka 原生支持重复消费旧消息（已经被消费过的消息），RabbitMQ 消息消费就会被销毁。

这是一个很有用的特性，可以做很多事情：

  • 利用类似流量回放的方式，重复消费某时间段内的消息，进行错误排查；

  • 开发可以实验性地消费生产日志，以进行开发，测试或调试，而不必担心会中断生产服务；

  • 使用流处理的思想，通过输入，得到输出，衍生更多其他系统；

在我看来，这是一个区分 Kafka 和 RabbitMQ 的根本特性，

Kafka 并没有队列 (queue) 的概念，不存在消息出队列就被销毁，都是日志，可以压缩日志。

Not only message system

来看官方对自己的定义：

Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.

event streaming platform，不仅是消息，事件的处理，还可以承担流处理。

事实上，相当于站在消息传递的更抽象层，即把消息，事件都抽象做流，

大流就是数据量巨大的 stream，可以是高质量的视频音频流，

小流自然就是平时互联网当中的一个一个请求事件。

又因为 Apache Kafka 强大的性能，还可以支持量大管饱的大数据量的流处理。

这样比较起来，基于 AMQP 的等等 MQ 之辈显然是不能跟 Kafka 比的。

结论

通过这次对 《DDIA》的阅读，使得我去对 Kafka 有了一次重新去了解的想法，不得不再次感叹它的强大，对它的工作原理有了更深的理解。对于它的某些特性，能做的事情很多，有时候只是没有场景，或者并没有想到去用它解决。

同时也再次证明一个道理，开源世界里面，谁被使用的最多，是有它的道理的，应该更多去关注这些新的产品，了解它们的原理。

因为它真的很强大，不要怀疑大家的技术眼光，所有人都会用脚投票。

reference

Updated on 2023-04-10
 Kafka
Back | Home