问与Apache Pulsar相比，Kafka的优点和缺点是什么

EN

最近我对这两种方法都进行了一些尝试，以下是我收集到的信息。

中性：

• 我打算让Kafka在社区/文档等方面获胜，但我无法轻松地找到对我在Kafka上的问题的回复，有些是旧的和令人困惑的(目标是遗留的API)。但是Pulsar文档已经足够好了，开发者在Slack (hello @Matteo Merli :)上的响应非常好，底层部分(Zookeeper，Bookkeeper)也有不错的文档，如果你想深入研究internals.
• Kafka的目标是高吞吐量，低延迟的Pulsar。两者都提供了控制它的设置。
• 都已经为生产做好了准备，并在几家公司进行了战斗测试

Pro脉冲星：

根据我的经验，

• 更容易使用。在Kafka中，经纪人是哑巴，消费者按照他们认为合适的方式来组织通信。这种灵活性是以Kafka的用户必须了解如何将各个部分组合在一起的成本为代价的。我猜预期的好处是增加了灵活性，但由于Pulsar能够复制Kafka Consumers (而且代码相当少)，我认为这是Pulsar的优势。geo-replication
• It
• 你可以做一些不容易做的事情(或者在Kafka中是不可能的)：多租户(安全，隔离...)，资源管理(主题节流，配额)，Kafka有一些Kafka目前缺乏的功能，比如寻求一个特定的API扩展到数百万个主题，而Kafka在Zookeeper
• Easier部署中构造数据的方式限制了Kafka。一个独立的Pulsar将启动它自己的本地Zookeeper，我个人发现，与遗留的Scala和Java代码的混合相比，在Java中使用understand
• written更容易进行配置。此外，我发现代码库组织得很好，也更容易理解。这在一定程度上是因为它依赖于Zookeeper和Bookkeeper，它们是外部项目，有自己的文档/社区/开发人员等(请注意，这些项目也在Apache foundation中，也来自雅虎，因此它们可以很好地合作)。

专业卡夫卡：

• Kafka有一些构建在顶部的东西，比如Kafka Streams (从未使用过，所以我不能说是否有类似的)

另请阅读：

• https://news.ycombinator.com/item?id=12453080
• https://news.ycombinator.com/item?id=15601222
• https://streaml.io/blog/why-apache-pulsar/
• https://kafka.apache.org/uses

Apache Kafka更成熟(它存在的时间更长)，并且拥有更高级别的API(即KStreams)。它的成熟度限制了流动性和灵活性，例如github上大约500个开放的PR

Apache Pulsar深入研究了Apache Kafka的设计决策，并结合了一种改进的设计和一组令人兴奋的功能，即命名空间主题的想法，并且允许在名称空间级别应用ACL或配额似乎是一个如此深刻的好主意，以提供更好的多租户支持。脉冲星的其他一些令人兴奋的特征是geo-replication，以及排队和流的统一

我们需要一个具有持久主题、合理延迟和高吞吐量的流媒体平台。最近，我们评估了是否应该使用Kafka或Pulsar，与@nha不同，我们现在支持Apache Kafka。以下是我们的发现：

脉冲星- Pros

• 具有丰富的持久性/非持久性主题、多租户、ACL、多数据中心复制等功能。
• 更灵活的客户端API，包括CompletableFutures、流畅的接口等。
• java客户端组件是线程安全的-使用者可以确认来自不同线程的消息

脉冲星- Cons

currently

• messageId客户端几乎没有javadoc

• small社区-8个堆栈溢出问题currently

• messageId概念与相关-与Kafka offset相比，消费者不能轻松地在主题上定位自己，Kafka offset是连续序列的
• 无法轻松读取主题中的最后一条消息-需要从头到尾浏览所有消息。Zookeeper没有BookKeeper操作复杂性-
• + Broker节点+ BookKeeper -所有clustered
• latency都有问题- Broker节点和Kafka之间有一个额外的远程调用(与Kafka相比)

Kafka - Pros

message node非常丰富且有用的javadoc

• Kafka Streams

• mature和广泛的community

• simpler操作于生产环境中-- broker节点还提供了storage

• transactions --原子读写在topics

• offsets内形成一个连续的序列--
• 用户可以轻松地寻找到最后的消息

Kafka -- Cons

• 使用者无法确认来自不同线程的消息
• 无多租户
• 无可靠的多DC复制-(在Confluent企业版中提供)