写点什么

选择 Pulsar 而不是 Kafka 的 7 大理由

作者:Apache Pulsar
  • 2021 年 11 月 17 日
  • 本文字数:2034 字

    阅读完需:约 7 分钟

以下文章来源于 AI 前线,作者 AI 前线小组 译


本文由微信公众号 「AI 前线」原创(ID:ai-front),未经授权不得转载。

作者 | Chris Bartholomew

译者 | 无明

编辑 | Natalie


AI 前线导读:对于云原生分布式应用程序的开发人员来说,为把更多精力放在应用程序和微服务开发上,而不是浪费时间处理复杂的消息基础架构,他们需要一个解决方案帮助管理好这些基础架构。


构建消息基础架构的第一步是选择合适的消息中间件技术。可选方案有很多,从各种开源框架(如 RabbitMQ、ActiveMQ、NATS)到一些商用产品(如 IBM MQ 或者 RedHat AMQ),除此之外,我们还有 Kafka。不过,我们最后没有使用 Kafka,而是选择了 Pulsar。


为什么最终选择了 Pulsar?下面列出了选择 Pulsar 而不是 Kafka 的 7 大理由。

1. 流式处理和队列的合体


Pulsar 就像一个合二为一的产品,不仅可以像 Kafka 那样处理高速率的实时场景,还支持标准的消息队列模式,比如多消费者、失效备援订阅和消息扇出等等。Pulsar 会自动跟踪客户端的读取位置,并把这些信息保存在高性能的分布式 ledger(BookKeeper)当中。


与 Kafka 不同,Pulsar 具备传统消息队列(如 RabbitMQ)的功能,因此,只需要运行一个 Pulsar 系统就可以同时处理实时流和消息队列。

2. 支持分区,但不是必需的


如果你用过 Kafka,就一定知道分区是怎么回事。Kafka 中的所有主题都是分区的,这样可以增加吞吐量。通过分区进而划分到不同的 broker,单个主题的处理速率可以得到大幅提升。但如果某些主题不需要太高的处理速率,又该怎么办呢?对于这类情况,如果能不考虑分区,避免随之而来的 API 和管理工作,不是更好吗?


Pulsar 就可以做到。如果只需要一个主题,可以使用一个主题而无需使用分区。如果需要保持多个消费者实例的处理速率,也不需要使用分区,Pulsar 的共享订阅可以达到这一目的。

如果确实需要分区来进一步提升性能,Pulsar 也可以支持分区的使用。

3. 日志固然不错,但 ledger 更胜一筹


Kafka 开发团队预见了日志对于一个实时数据交换系统的重要性。日志通过追加的方式写入系统,写入速度很快。日志中的数据是串行的,可以按照写入的顺序快速读取数据。相比随机读取和写入,串行读取和写入速度更快。对于任何一个提供数据保证的系统来说,持久化存储方面的交互都是一个瓶颈,而日志抽象最大限度地提升了这方面的效率。


日志固然好,但当数据量过大时,也会给我们带来一些麻烦,单台服务器上保存所有日志已经成为一个挑战。在日志占满服务器存储之后该怎么办?如何进行扩容?或者保存日志的服务器宕机,需要重新从副本创建新的服务器时,该怎么办?将日志从一台服务器拷贝到另一台服务器耗时很长,特别是想要同时保持系统实时数据时,完成这个操作就更难了。


Pulsar 对日志进行分段,从而避免了拷贝大块的日志。通过 BookKeeper, Pulsar 将日志分段分散到多台不同的服务器上。也就是说,日志不会保存在单台服务器上,任何一台服务器都不会成为整个系统的瓶颈。这使故障处理和扩容更加简单,只需要加入新的服务器,而无需进行再均衡处理。

4. 无状态


对于云原生应用程序开发人员来说,最喜欢的东西就是无状态。无状态组件启动速度快、可替换,还可以实现无缝扩容。如果消息中间件也是无状态的,那岂不是更好?


Kafka 不是无状态的,每个 broker 都包含了分区的所有日志,如果一个 broker 宕机,不是所有 broker 都可以接替它的工作。如果工作负载太高,也不能随意添加新的 broker 来分担,而是必须与持有其分区副本的 broker 进行状态同步。


在 Pulsar 架构中,broker 是无状态的。但是完全无状态的系统无法持久化消息,所以 Pulsar 不是依靠 broker 来实现消息持久化的。在 Pulsar 架构中,数据的分发和保存是相互独立的。broker 从生产者接收数据,然后将数据发送给消费者,但数据保存在 BookKeeper 中。


Pulsar 的 broker 是无状态的,所以如果工作负载很高,可以直接添加新的 broker,快速接管工作负载。

5. 简单的跨域复制


跨域复制是 Pulsar 的拿手好戏。Pulsar 在设计之初就考虑到了这个特性,配置也很容易。无论是全局分布式应用程序还是灾备方案,都可以通过 Pulsar 搞定。

6. 稳定的表现


基准测试(http://openmessaging.cloud/docs/benchmarks/pulsar/)表明,Pulsar 可以在提供较高吞吐量的同时保持较低的延迟。

7. 完全开源


Pulsar 提供了很多与 Kafka 相似的特性,比如跨域复制、流式消息处理(Pulsar Functions)、连接器(Pulsar IO)、基于 SQL 的主题查询(Pulsar SQL)、schema registry,还有一些 Kafka 没有的特性,比如分层存储和多租户。更赞的是,这些功能特性都是开源的。

结 论


以上,我们有很多理由选择 Pulsar 来构建消息基础架构服务。除了上述原因之外,Pulsar 的其他特性也带来了很多便利,比如多租户、命名空间、认证和授权、文档、对 Kubernetes 的友好支持等等。


英文原文:

https://kafkaesque.io/7-reasons-we-choose-apache-pulsar-over-apache-kafka/


更多关于 Apache Pulsar 的动态和干货分享,请关注 ApachePulsar 公众号!



用户头像

Apache Pulsar

关注

下一代云原生分布式消息流平台 2017.10.17 加入

Apache 软件基金会顶级项目,集消息、存储、轻量化函数式计算为一体,采用计算与存储分离架构设计,支持多租户、持久化存储、多机房跨区域数据复制,具有强一致性、高吞吐、低延时及高可扩展流数据存储特性。

评论

发布
暂无评论
选择 Pulsar 而不是 Kafka 的 7 大理由