使用Apache Pulsar 而不是Apache Kafka构建我们的消息服务

Pulsar github 下载地址 https://github.com/apache/pulsar.git

那么为什么我们使用Apache Pulsar构建我们的消息服务呢？

1.流和队列 一起Apache Pulsar就像两个产品一样。它不仅可以处理像Kafka这样的高速实时用例，而且还支持标准的消息队列模式，例如竞争消费者，故障转移订阅和简单的消息扇出。 Apache Pulsar会自动跟踪主题中的客户端读取位置，并将该信息存储在其高性能分布式账本Apache BookKeeper中。
与Kafka不同，Apache Pulsar可以处理传统排队系统的许多用例，例如RabbitMQ。因此，不是运行两个系统，一个用于实时流，一个用于排队，而是使用Pulsar。这是一个两比一的交易，而且总是好的。

2.分区，但不是必需的分区如果你使用Kafka，你就知道分区。所有主题都在Kafka中分区。分区很重要，因为它可以提高吞吐量。通过将工作分散到多个分区以及多个代理，可以由单个主题处理的速率上升。但是，如果您有一些不需要高费率的主题，该怎么办？在这些简单的情况下，不必担心分区以及随之而来的API和管理复杂性，这不是很好吗？
好吧，使用Apache Pulsar就可以这么简单。如果您只需要一个主题，那么请使用主题。您不必指定分区数或考虑该主题可能具有的消费者数量。 Pulsar订阅​​允许您在Pulsar跟踪所有主题的主题上添加任意数量的消费者。如果您的消费应用程序无法跟上，您只需使用共享订阅即可在多个使用者之间分配负载。
如果你确实需要分区主题的性能，你也可以这样做。如果您需要，Pulsar会对主题进行分区，但前提是您需要它们。

3.日志是好的，分布式账本更好.
Kafka团队值得称赞的是日志是实时数据交换系统的一个很好的抽象。因为日志是仅附加的，所以可以快速地将数据写入它们，并且因为日志中的数据是顺序的，所以可以按照写入的顺序快速提取日志。顺序读写是快速的，随机的不是。持久存储交互是任何提供数据保证的系统的瓶颈，而日志抽象使这一点尽可能高效。
简单的日志很棒，但是当它们变大时它们会让你陷入麻烦。在单个服务器上安装日志成为一项挑战。如果它变满并且您需要扩展会发生什么？如果存储日志的服务器出现故障并需要从副本重新创建，会发生什么？将大型日志从一台服务器复制到另一台服务器虽然有效，但仍然需要很长时间。如果您的系统在保持实时数据的同时尝试这样做，那么这可能是一个非常大的挑战。
Apache Pulsar通过将日志分成多个段来避免复制大型日志的问题。它通过使用Apache BookKeeper作为其存储层来编写数据时，将这些段分布在多个服务器上。这意味着日志永远不会存储在单个服务器上，因此单个服务器永远不会成为瓶颈。失败场景更容易处理，扩展也很容易。只需添加另一台服务器不需要重新平衡。

4.broker是无状态的,数据的代理与数据的存储是分开
无状态是构建云原生应用程序的任何人的耳朵。无状态组件快速启动，可互换，无缝扩展。如果消息经纪人无状态，那不是很好吗？
kafka不是无状态的。每个代理包含其每个分区的完整日志。如果一个经纪人失败，不只是任何经纪人可以接管它。如果负载过高，则无法简单地添加其他代理。代理必须与包含其分区副本的其他代理同步状态。
在Apache Pulsar架构中，broker是无状态的。是的，你听到的是对的。一个完全无状态的系统将无法持久保存消息，因此Apache Pulsar确实维持状态，而不是在经纪人中。在Pulsar架构中，数据的代理与数据的存储是分开的。经纪人接受来自生产者的数据并将数据发送给消费者，但数据存储在Apache BookKeeper中。
因为Pulsar经纪人是无状态的，如果负担变高，你只需要添加另一个Broker。Broker迅速启动并立即开始工作。

5.对于DUMMIES的地理复制Geo-replication是Pulsar的一流功能。它不是一个插件或专有插件。 Pulsar的设计考虑了地理复制。配置它很容易，它只是工作。因此，无论是全局分布式应用程序还是灾难恢复方案，您都可以使用Pulsar进行设置。

6.一致的基准测试表明Pulsar提供更高的吞吐量以及更低和更一致的延迟。更快，更一致更好。

7.它是所有APACHE开源Pulsar具有许多与Kafka相同的功能，例如地理复制，流内消息处理（Pulsar功能），输入和输出连接器（Pulsar IO），基于SQL的主题查询（Pulsar SQL） ），模式注册表，以及功能Kafka没有像分层存储和多租户。所有这些功能都是Apache开源项目的一部分。
Pulsar不是由商业实体控​​制的开源和闭源功能或开源功能的集合。所有许多有用的功能都是Apache下的开源软件。除非不可想象的事情发生，所有这些善良都会保持开源。
结论正如您所看到的，我们有很多理由选择Apache Pulsar来构建我们的消息传递基础结构服务。我们甚至没有考虑到更容易在Pulsar周围建立服务的原因，例如多租户，命名空间，身份验证和授权，文档，Kubernetes友好性。

对我们来说，使用Apache Pulsar而不是Kafka（或任何其他消息传递解决方案）是一个简单的选择。