这是我参与「第四届青训营 」笔记创作活动的第十二天
Kafka 不足
- Kafka 没有租户概念，需要手动维护多个集群，不方便运维。
- Kafka 集群扩容后需要做 Reassign Partitions，IO 消耗大。
- Kafka 监控体系不完善，排查问题较为繁琐。
- 在线业务消息重置不方便，实现起来较为麻烦，需要停掉消费组。
- Kafka 不支持死信队列和延迟队列。
- Kafka 没有官方维护和支持的 Go 语言客户端。
- 在 Kafka 中支持 schema，需要引入额外组件，不方便维护。
Pulsar的优势
可靠消息与性能
现有的消息队列让很多人都形成了一个惯性思维，即如果一个消息队列的消息是可靠的，那么它的性能肯定很差，因为同步刷盘、数据同步等会消耗时间。
而Pulsar基本做到了可靠消息与性能的平衡。即使在很高吞吐量的场景下，也能保证消息的可靠性，还能保证单点的性能。由于受到每条消息大小的影响，用QPS来计算性能可能不太合适，用每秒的流量来计算性能可能更准确。
在保证消息可靠的前提下，把单台机器的网卡带宽用满还是很容易的，最终的性能瓶颈要么在硬盘，要么在网卡。
Pulsar的性能是我们平常使用的一些消息队列无法比拟的。这其实得益于Pulsar的Quorum机制与条带化写入策略。
低延迟
很多业务对消息延迟有很高的要求，现有的一些队列，要么延迟很小但吞吐量低，要么延迟很大但吞吐量高，而Pulsar则是一个两者可以兼得的消息队列。 Pulsar官方做了一个Pulsar与Kafka全方位对比的测试，对比文章中显示，Kafka在100个Partition时，99%的延迟小于18.75ms，在5000个Partition的时候消息延迟开始大幅上升，99%的延迟小于79236ms。Pulsar从100、5000一直到10000个Partition，在单个Broker同步返回算成功的情况下，延迟一直保持在10ms以下；在两个Broker同步返回算成功的场景下，延迟一直保持在20ms以下。可见，Pulsar在低延迟方面的表现还是非常优秀的。
高可用的分布式消息队列
Pulsar是一个真正意义上的分布式消息队列，自带了各种容灾方案。我们可以根据不同业务的RTO（Recovery Time Objective）、RPO（Recovery Point Objective）来决定使用哪一种。
首先，异步的跨地域复制（Geo Replication）可以实现两个集群之间的主备复制、互备复制等。这种方式在一个集群完全宕机的情况下，另外一个集群可以继续提供服务，但数据有一定的时间间隔的损失，这取决于网络延迟和异步复制延迟。另外一种是强一致的复制方式，这种方式在官方的文档中没有写出来，但我们可以通过BookKeeper的跨机架配置，或者配置Quorum的全ACK方式来实现。这种开箱即用的方式，让我们在架构设计上省去了很多的工夫。
流批一体
随着业务的不断发展，流计算和批处理越来越常见，通常我们需要分别维护一套流计算平台和批处理平台以满足不断发展的业务需求。而Pulsar可以同时支持两种计算方式，只需要维护一套中间件即可实现流批一体。
完整的历史数据可以让我们做批计算，数据在某段时间内可以变为流。流和批本来就是硬币的两面，随着业务的不断发展，单纯使用流计算或者批处理都无法满足业务的需求。Pulsar使用Segment分片存储可以很方便地支持流计算，使用分层存储又可以很好地支持批处理。我们再也不用把数据从不同的存储中迁移、转换了，Pulsar天然支持流批融合。再基于函数的能力，Pulsar可以很容易和其他流计算和批计算平台对接，成为它们的数据源或者消息存储节点。
多协议、功能丰富
Pulsar是一个融合的消息系统。
除了自己的通信协议，还支持其他消息队列的协议，比如支持Kafka协议的KOP、AMQP、MQTT协议等。这让其他消息队列迁移到Pulsar的成本大大降低，方便内部统一消息队列。
对比其他消息队列，Pulsar的功能非常丰富，比如延迟队列、死信队列、顺序消息、主题压缩（相同Key消息只保留最新一条）、多租户、认证授权、分层存储（冷热分离）、跨地域复制等。基本上日常业务需要的能力，Pulsar都能满足。这就让一套消息队列能支持众多的业务，不会因为无法提供某些业务能力而又要维护另外一类消息队列，降低了内部团队的运维成本。
