pulsar相对于kafka的优点

前言

对于开发云原生分布式应用程序的开发人员来说，他们应该把更多的精力放在应用程序和微服务上，而不是把时间浪费在处理复杂的消息基础设施上，他们需要一些解决方案帮助他们管理好这些基础设施。
构建消息基础设施的第一步是选择合适的消息中间件技术。在这方面有很多选择，从各种开源框架（如 RabbitMQ、ActiveMQ、NATS）到一些商用产品（如 IBM MQ 或者 RedHat AMQ）。当然，除了这些之外，我们还有 Kafka。不过，我们最后并没有选择 Kafka，而是选择了 Pulsar。

为什么我们最终选择了 Pulsar？下面列出了选择 Pulsar 而不是 Kafka 的 理由如下

流式处理和队列的合体

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

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

支持分区，但不是必需的

如果你用过kafka,就一定知道分区是怎么回事。Kafka中的所有主题都是分区的，这样可以增加吞吐量。通过分区，单个主题的处理速率可以得到大幅提升。但如果某些主题需要太高的处理速率，那该怎么办？对于这类情况，就不需要考虑分区了，以避免复杂的 API 和管理方面的工作，这样不是更好吗？

Pulsar 就可以做到。如果你只需要一个主题，而不需要分区，那使用一个主题就好了。如果你需要使用多个消费者实例来提升处理速率，其实也不需要使用分区，因为 Pulsar 的共享订阅可以达到你的目的。

如果你确实需要分区来进一步提升性能，你也可以使用分区。

日志固然不错，但ledger更胜一筹

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

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

Pulsar 对日志进行分段，从而避免了拷贝大块的日志。它通过 BookKeeper 将日志分段分散到多台不同的服务器上。也就是说，日志并不是保存在单台服务器上，所以任何一台服务器都不会成为整个系统的瓶颈。这样就可以更容易地处理故障，要进行伸缩也很容易，只需要加入新的服务器，不需要进行再均衡。

无状态

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

Kafka 不是无状态的，因为每个 broker 都包含了分区的所有日志，如果一个 broker 宕机，并非任意一 broker 都可以接替它的工作。如果工作负载太高，也不能随意添加新的 broker 来分担。broker 之间必须进行状态同步。

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

因为 Pulsar 的 broker 是无状态的，所以如果工作负载很高，就可以直接添加新的 broker。

简单的跨域复制

跨域复制是 Pulsar 的拿手好戏。Pulsar 在设计之初就考虑到了这个特性，配置也很容易。要搭建一个全球化的分布式 Pulsar 集群，并不需要你拥有博士学位。
稳定的表现

一些基准测（http://openmessaging.cloud/docs/benchmarks/pulsar/）表明，Pulsar 可以在提供较高吞吐量的同时保持较低的延迟。

完全开源

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

结 论

为此，我们有理由选择 Pulsar 来构建我们的消息基础设施服务。其实除了上述这些原因之外，使用 Pulsar 还有其他好处，比如多租户、命名空间、认证和授权、文档、对 Kubernetes 的友好支持。