Go最全深入了解 Kafka 和 Pulsar 的区别_pulsar消息队列和kafka区别(1)，2024最新Golang面试笔试题目分享

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

消息队列 （MQ） 和发布-订阅 （Pub/Sub） 是两种流行的消息传递模型。MQ 具有简单的逻辑，具有悠久的历史，存在于从数据结构到操作系统流水线的各个领域。MQ 由一个队列组成，该队列在发送方和接收方之间保存消息。消息管道的特征包括：

• 无数据存储
• 无数据保留
• 无消费状态跟踪（光标）

然而，在大数据时代，这种“一次读即删”的模式（发布一次、消费一次、删除一次）已经无法满足数据繁荣的需求。单个消息队列的吞吐量有限;当数据量超过单个队列的容量时，我们需要多个业务部门（队列）来处理数据。这是一种常见的分布式模型，此类队列也称为消息代理。

代理是处理消息的程序，充当彼此独立的中介。当我们有多个代理时，每个代理都会处理一部分数据。如果数据没有顺序要求，则处理逻辑非常简单。这类似于 MapReduce，它允许您在再次聚合之前对问题进行划分和单独处理。当数据量达到一定水平时，这是一个经典的解决方案。

Pub/Sub 模型的成熟度

随着数据量的增长，越来越多的业务场景需要分布式处理。数据可能来自多个生产者，并且只有一个使用者使用数据。

那么，我们是如何处理这个新模型的呢？简单地说，为了处理大约 80% 的 MQ 场景（海量数据处理），该模型被抽象出来，以推动专门用于分布式处理的新产品的开发，包括 Apache Kafka。

这种新模式带来了新的市场机遇，同时也面临着新的挑战，包括：

• 海量数据存储、消费状态跟踪（游标）和中间状态存储。
• 延迟读取、重复读取、多次读取和从特定位置读取。
• 消费隔离和资源管理
• 实时处理、高吞吐量、低延迟
• 事务
• 高扩展性
• 企业功能和安全性

为了提供一个更具体的例子，考虑一个电信供应商，它需要从全国用户那里收集某些数据。由于数据量巨大，不可能直接从所有用户那里收集它们。另一种解决方案是按区域对数据进行分区。在为每个分区独立收集数据后，可以对数据进行聚合。这种模式在当今的消息传递中间件解决方案中非常普遍，并导致了行业先驱 Kafka 的出现。

Kafka 在早期确实面临一些挑战，并不断发展以满足市场需求。今天，Kafka 被认为是大数据时代事实上的领导者或“潮汐骑士”。

Kafka：潮汐骑士

Apache Kafka 实现了一个经典的分布式系统。为了处理数据分区，Kafka 将整个分区数据存储在每个节点（即 Broker）中，该节点负责计算和存储。一个分区可以有多个副本，相应的副本同时存储在分区领导者和同步副本 （ISR） 中。这种开创性的分布式处理方法有效地解决了 Kafka 诞生时的一系列挑战，例如峰值削波和异步通信。具有高性能（高吞吐、低时延）和数据持久化等特点，满足大数据时代的数据迁移需求。

多年来，由于蓬勃发展的开源社区和商业公司支持该项目，一个全面的 Kafka 生态系统已经形成。许多大大小小的企业都认可了 Kafka，这充分说明了它作为一个产品的成熟度。

虽然 Kafka 的简单架构使其能够快速发展并抢占先机，但它也为适应不同场景的潜在困难留下了空间。其中一些挑战包括：

• 重新平衡的痛苦
• 难以扩展代理、主题、分区和副本
• 代理故障处理
• 延迟和抖动
• 企业级功能
• 云迁移

Kafka 出现在 2010 年左右，当时正值大数据的最初爆炸式增长时期。随着数据量在随后的几年中持续增长，功能要求和易用性变得越来越重要。更重要的是，“云原生”的概念开始受到关注，这预示着 Kafka 的新挑战者，Apache Pulsar 就是其中的佼佼者。

Pulsar：为云原生而生

Kafka 的经典架构启发了许多后继者，包括 Apache Pulsar。作为面向云原生环境的下一代消息传递平台，Pulsar 拥有用于计算和存储的解耦架构。

Pulsar broker 作为计算层，而存储则由另一个 Apache 顶级项目 Apache BookKeeper 支持，Apache BookKeeper 是一个分布式预写日志 （WAL） 系统。BookKeeper 可以有效地处理大量数据存储任务，元数据来源于 ZooKeeper。

Pulsar 的分层架构、云原生兼容性以及多租户等开源企业特性，为用户在生产中提供了更多的可能性。然而，其复杂的结构也意味着更高的学习成本和就业市场上缺乏人才。这也是为什么像腾讯这样的大型科技公司已经认可了Pulsar，但较小的公司一直在努力采用它的原因。

与 Kafka 相比，Pulsar 还有很长的路要走，尤其是在其生态系统方面，但它自成立以来一直保持着强劲的势头。

• 2012 年：雅虎内部开发！
• 2016 年：在 Apache 2.0 许可下开源
• 2018 年：成为 Apache 顶级项目 （TLP）
• 2023：600+ 贡献者，12.5K+ Stars，3.3K+ Forks

2021 年，Pulsar 的月活跃贡献者数量超过了 Kafka。在成为 TLP 的相差 5 年的情况下（2013 年的 Kafka 和 2018 年的 Pulsar），Pulsar 如何解决 Kafka 的痛点？它们之间有哪些主要区别？有了上面的背景信息，让我们更详细地回顾一下这些问题。

代理和分区：是否解耦

第一个主要区别是两个系统如何处理代理和分区之间的关系。Kafka 的分区和代理是紧密耦合的。当生产者将数据发布到 Kafka 集群时，数据会写入分区。每个分区都有一个领导节点，该节点具有多个（或零个）跟随节点，这些节点在领导节点发生故障时复制数据。

这种做法最困难的部分是分区的数据迁移。如果 Kafka 分区中有大量数据，则迁移过程可能是一场噩梦。分区和代理之间的强耦合关系，在某种程度上导致了 Kafka 中的一系列其他问题。

相比之下，分区和代理在 Pulsar 中是松散耦合的。一个分区可以进一步划分为多个段，这允许跨多个存储节点（i.e. bookies）对条目进行条带化。换句话说，单个分区中的数据可以存储在具有多个副本的多个节点中。

在上图中，分区 1 中有许多剥离的数据段，段 1 在 Bookie 1、Bookie 2 和 Bookie 4 中可能有副本。如果其中一个 Broker 失败，对分区的影响是微不足道的，因为它可能只影响一个或几个部分。此外，与整个分区的数据丢失相比，恢复过程要快得多。

当 Kafka 在十多年前发展起来时，它需要快速增长，并没有优先考虑细粒度的数据存储和管理。相比之下，Pulsar 在这方面提供了更复杂的方式，为其未来的增长带来了更大的空间。

可扩展性

可伸缩性是区分这两种邮件系统的另一个关键因素。

在 Kafka 中，您有多个代理来接收数据（一个领导者具有多个 ISR）。如果发生节点故障，则该代理上的分区将丢失。它需要手动维护（或脚本）进行恢复，并且逻辑相对复杂。您不能简单地将其替换为新的代理，并且以前的代理 ID 无法自动转移。

另一个麻烦是，新代理无法立即处理旧代理的流量，因为新代理没有分区。您需要手动将旧分区迁移到代理。但是，如果数据量很大，则迁移可能会很麻烦，如上一节所述。

那么，Pulsar 是如何处理同样问题的呢？

如果 Pulsar broker 发生故障，它将失去之前持有的分区的所有权，该分区的信息存储在 ZooKeeper 中。检测到更改后，其他经纪人会重新选择新的经纪人。对于整个 Pulsar 集群来说，代理故障并不是一个重大问题，因为另一个代理可以快速接管。

这个过程的效率在于 Pulsar 经纪人是无状态的。当代理出现故障时，可以立即扩展代理集群。代理不存储数据，仅作为计算层。Broker 存储数据，他们甚至不需要知道经纪人方面发生了什么。

在 Pulsar 中丢失热分区的影响远小于 Kafka，恢复速度也快得多。如果需要提升集群处理消息的能力，只需添加 broker 即可，无需担心存储层。

热点传输

在 Kafka 和 Pulsar 中，broker 处理流量热点的能力和方法不同。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！**

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取