雅虎开发了Pulsar,pub-sub消息系统,并将其作为开源软件.它现在是Apache的孵化项目.由于卡夫卡也用于同一目的.想知道,卡夫卡超过Pulsar的主要加分和减分.
1> nha..：
我最近和两个人玩了一下,这就是我收集的内容.
中性:
我打算让Kafka赢得社区/文档等.但是我无法轻易找到对Kafka的问题的回复,有些陈旧而且令人困惑(针对遗留API).但是Pulsar文档已经足够好了,开发人员对Slack(hello @Matteo Merli :))非常敏感,而底层的部分(Zookeeper,Bookkeeper)也有很好的文档,如果你想潜入内部.
Kafka旨在实现高吞吐量,Pulsar的低延迟.两者都提供控制它的设置.
两家公司都已准备好生产并在几家公司中经过严峻考验
Pro脉冲星:
根据我的经验,API更易于使用.在卡夫卡,经纪人是愚蠢的,消费者在他们认为合适的情况下完成了构建沟通的工作.这种灵活性是以Kafka的用户必须了解如何使这些部件组合在一起为代价的.我想预期的好处是增加了灵活性,但是由于Pulsar能够复制Kafka Consumers API(并且代码相当少),我将其作为专业人士给予Pulsar.
你可以做一些不容易做的事情(或者在Kafka中可能不可能):多租户(安全,隔离......),资源管理(主题限制,配额),地理复制
它有一些Kafka目前缺乏的功能,比如寻找特定的MessageId
Pulsar扩展到数百万个主题,其中Kafka受到Zookeeper中数据结构的限制
部署更容易.一个独立的Pulsar将启动它自己的本地Zookeeper,我个人发现配置更容易理解
用Java编写,而不是传统的Scala和Java代码.此外,我发现代码库组织良好,更容易遵循.部分是因为它依赖于Zookeeper和Bookkeeper,它们是具有自己的文档/社区/开发人员等的外部项目(请注意,这些也在Apache基础中,也来自Yahoo,因此它们可以很好地协同工作).
Pro Kafka:
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
我很感激跪拜者的解释.
@ c69当然有偏见:)这是我的答案,你可能会有不同的意见,我很乐意考虑其他亲Kafka积分.让我偏向的是我首先和Kafka一起玩(并且没有计划进一步观察).但有些事情令人沮丧.然后我听说了脉冲星,它更适合(至少对我来说).
亲Pulsar:6项,亲Kafka:1项.我没有倒闭,但这个答案看起来有点偏颇.
2> Antonios Cha..：
Apache Kafka更成熟(它已存在更长时间)并且具有更高级别的API(即KStream).它是成熟的,但是限制了流动性和灵活性,即在github上打开~500
Apache Pulsar深入研究了Apache Kafka的设计决策,并结合了改进的设计和一系列令人兴奋的功能,即命名空间主题的概念,并允许ACL或配额应用于名称空间级别,这似乎是非常好的想法,提供更好的多租户支持.Pulsar的其他一些令人兴奋的功能是地理复制,以及排队和流媒体的统一
3> Milos Gregor..：
我们需要一个具有持久主题,合理延迟和高吞吐量的流媒体平台.最近,我们评估了我们是否应该选择Kafka或Pulsar,而不像@nha,我们现在支持Apache Kafka.以下是我们的发现:
Pulsar - 优点
功能丰富 - 持久性/非持久性主题,多租户,ACL,多DC复制等.
更灵活的客户端API - 包括CompletableFutures,流畅的界面等.
java客户端组件是线程安全的 - 消费者可以确认来自不同线程的消息
Pulsar - 缺点
java客户端几乎没有javadoc
小社区 - 目前有8个stackoverflow问题
与BookKeeper相关联的messageId概念 - 与连续数字序列的Kafka偏移相比,消费者无法轻易地将自己定位于该主题.
Reader无法轻松阅读主题中的最后一条消息 - 需要浏览所有消息到最后.
没有交易
更高的操作复杂性 - Zookeeper + Broker节点+ BookKeeper - 全部集群
延迟可疑 - Broker节点和BookKeeper之间有一个额外的远程调用(与Kafka相比)
卡夫卡 - 职业选手
非常丰富和有用的javadoc
卡夫卡流
成熟和广泛的社区
在生产中操作更简单 - 更少的组件 - 代理节点也提供存储
事务 - 主题内的原子读取和写入
抵消形成一个连续的序列 - 消费者可以轻松寻求最后的消息
卡夫卡 - 缺点
消费者无法确认来自不同线程的消息
没有多租户
没有强大的多DC复制 - (在Confluent Enterprise中提供)
>与BookKeeper相关的messageId概念 - 与连续数字序列的Kafka偏移相比,消费者无法轻易地将自己定位于该主题.---消费者可以使用messageId定位任何消息.MessageId也可以存储在Pulsar之外,用于回滚到特定的消息.
2.(最后一个条目)Reader可以指定MessageId.latest将自己定位到流的末尾
4（等待时间有问题）-这是不正确的。首先，Kafka还具有额外的网络跃点（复制到另一个代理时）。其次，与Kafka相比，具有BookKeeper的Pulsar可以保证比Kafka更低的延迟，甚至可以提供比Kafka内存中页面缓存方法更高的持久性。消息传递系统的延迟通常由磁盘访问模式而不是网络控制。
3.（操作复杂性）-对于小型集群，建议的部署模式是将经纪人和簿记员结合在一起。与Kafka的组件数量相同
1个额外的网络跃点约为0.1毫秒，Pulsar可以保证99pct的延迟小于5毫秒，而Kafka通常为15毫秒（无数据持久性），峰值为100毫秒（对于99pct）。您可以使用OpenMessaging基准测试不同的消息传递系统：http://openmessaging.cloud/docs/benchmarks/
@MatteoMerli您如何有效地使用主题的最新发布消息？恕我直言，这不可能不浏览整个主题，而在Kafka中，您只想寻找`lastOffset -1`。
京公网安备 11010802041100号