要理解 Apache Pulsar 与 Apache Kafka 的差异，需从核心定位、架构原理、存储模型、扩展性等维度对比，二者虽同属分布式流处理平台，但设计理念和技术实现存在显著区别。以下是详细的异同点分析，重点突出架构原理的差异：
一、相同点（核心共性）
Pulsar 和 Kafka 作为主流流处理平台，均满足高吞吐、低延迟的流数据传输需求，核心共性如下：
- 定位一致：均为分布式发布 - 订阅（pub/sub）消息队列，支持流数据的实时采集、传输、存储与处理，广泛用于日志聚合、实时分析、事件驱动架构等场景。
- 持久化存储：均将消息持久化到磁盘，避免内存溢出，且支持通过 "副本机制" 保障数据可靠性（防止单点故障）。
- 分区机制：均支持 "topic 分区"（Partition），通过分区实现负载均衡和水平扩展（单个 topic 的不同分区可由不同节点处理）。
- 高可用保障：均依赖分布式协调组件（早期均用 ZooKeeper，Kafka 新版支持 KRaft 替代）实现集群元数据管理、节点选举、故障恢复。
- 流处理集成：均提供原生流处理框架（Pulsar 有 Pulsar Functions，Kafka 有 Kafka Streams），支持基于消息流的实时计算（如过滤、聚合、关联）。
- 多客户端支持：均提供多语言客户端（Java、Python、Go 等），兼容主流开发生态。
二、不同点（核心差异）
二者的本质差异源于架构设计理念：Pulsar 采用 "计算与存储分离" 架构，Kafka 早期采用 "计算与存储耦合" 架构（新版 KRaft 未改变存储耦合本质）。以下从 7 个核心维度展开对比：
1. 架构原理：分离 vs 耦合
这是二者最根本的差异，直接决定了扩展性、运维复杂度和功能灵活性。
| 维度 | Apache Pulsar | Apache Kafka（默认架构，非 KRaft） |
|---|---|---|
| 核心组件构成 | 3 层架构：1. Broker 层 （无状态，仅负责消息路由 / 分发）2. BookKeeper 层 （独立存储层，负责消息持久化）3. 协调层（ZooKeeper/etcd，含集群级 ZooKeeper + 实例级配置存储） | 2 层架构：1. Broker 层 （有状态，既负责消息路由，也存储消息）2. 协调层（早期 ZooKeeper，新版 KRaft 集成协调功能） |
| 组件职责分工 | - Broker 无状态：不存储消息，仅处理生产者 / 消费者连接、消息转发，依赖 BookKeeper 读取 / 写入数据- BookKeeper：分布式存储集群（由 Bookie 节点组成），专门负责消息的多副本持久化- 配置存储：管理跨集群元数据（如 geo-replication） | - Broker 有状态：每个 Broker 存储多个 topic 分区的消息日志，同时处理请求- ZooKeeper/KRaft：管理元数据（如分区归属、消费组进度），不负责消息存储 |
| 架构核心理念 | 计算（Broker）与存储（BookKeeper）完全分离，各司其职 | 计算与存储耦合，Broker 兼具 "转发" 和 "存储" 双重职责 |
2. 存储模型：多 Ledger 动态管理 vs 分区日志段静态分割
存储模型的差异决定了消息生命周期管理、回溯效率和存储扩展性。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| 存储抽象 | 基于 Managed Ledger + BookKeeper Ledger ：- 每个 Topic 对应 1 个 Managed Ledger- 每个 Managed Ledger 由多个 BookKeeper Ledger 组成（动态创建 / 删除）- Ledger 是 append-only 结构，单写入者，多副本同步 | 基于 分区日志段（Log Segment） ：- 每个 Topic 分区对应 1 个 "日志文件集合"- 日志按大小 / 时间分割为多个 Log Segment（静态分割，如 1GB / 段）- 每个分区的副本是 "完整日志副本"，存储在不同 Broker 上 |
| 副本机制 | 条目级副本：消息条目（Entry）写入时同步到 N 个 Bookie（如 3 副本），副本分散在不同 Bookie，与 Broker 无关 | 分区级副本：整个分区的日志副本存储在不同 Broker 上（如 3 副本，1 个 Leader 负责读写，2 个 Follower 同步） |
| 消息生命周期 | - 当所有消费者消费完某个 Ledger 的消息后，该 Ledger 可被直接删除（无碎片）- 支持 "按时间 / 大小 / 消费进度" 灵活清理 | - 日志段需等待 "所有分区副本同步完成" 后，按 "日志保留策略"（如 7 天 / 100GB）删除- 可能产生存储碎片（需定期压缩） |
| 消费进度存储 | 消费进度（Cursor）存储在 BookKeeper，与 Broker 无关（Broker 重启不丢失进度） | 消费进度（Offset）存储在 ZooKeeper/KRaft（早期）或 Broker（新版），与分区绑定（Broker 故障可能需恢复 Offset） |
3. 扩展性：无状态扩容 vs 有状态迁移
架构的 "分离 / 耦合" 直接影响扩展能力，Pulsar 在 Broker 和存储扩容上更灵活。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| Broker 扩容 | Broker 无状态，新增 Broker 后：- 只需在协调层注册，即可立即接收请求- 无需迁移数据（数据在 BookKeeper）- 负载均衡由 Broker 内置 Balancer 自动完成 | Broker 有状态，新增 Broker 后：- 需手动 / 自动将现有分区 "迁移" 到新 Broker（数据随分区迁移）- 迁移过程可能影响性能- 负载均衡依赖 "分区重分配工具" |
| 存储扩容 | 新增 Bookie 节点后：- BookKeeper 自动将新 Ledger 分配到新 Bookie- 现有数据无需迁移，存储容量 / 吞吐量线性提升 | 存储扩容需通过 "增加分区副本" 或 "拆分分区" 实现：- 增加副本仅提升可靠性，不提升容量- 拆分分区需手动操作，且可能中断服务 |
| 跨集群扩展 | 原生支持 Geo-Replication（跨地域复制）：- 通过 "配置存储" 同步元数据- Broker 内置 Replicator 自动转发消息到远程集群 | 需依赖第三方工具（如 MirrorMaker 1/2）实现跨集群复制：- 配置复杂，需手动管理复制进度- 延迟较高，可靠性依赖工具配置 |
4. 消息模型：多模式支持 vs 消费组绑定
Pulsar 提供更灵活的消费模式，适配更多业务场景。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| 消费模式 | 支持 4 种消费模式：1. 独占消费（Exclusive）：1 个消费者独占 1 个 Topic2. 共享消费（Shared）：多消费者分摊消息（轮询 / 哈希）3. 故障转移（Failover）：主消费者故障后，从消费者接管4. 键共享（Key_Shared）：同 Key 消息路由到同一消费者 | 仅支持 "消费组（Consumer Group）" 模式：- 1 个分区只能被 1 个消费组内的 1 个消费者消费（分区与消费者 1:1 绑定）- 多消费组可独立消费同一 Topic，但单消费组内无法多消费者共享 1 个分区 |
| 多租户支持 | 原生支持多租户：- 按 "租户（Tenant）→ 命名空间（Namespace）→ Topic" 分层管理- 可对租户配置资源配额（如 Broker 吞吐量、BookKeeper 存储） | 无原生多租户：- 需通过 "Topic 命名前缀"（如 tenant1_topic）模拟- 资源隔离需依赖外部工具（如 Kafka ACL + 集群划分） |
| 消息类型 | 支持两种存储类型：1. 持久化消息（Persistent）：写入 BookKeeper，保障不丢失2. 非持久化消息（Non-Persistent）：仅存内存，性能更高 | 仅支持持久化消息（早期无内存消息，新版可通过 "日志保留 0 秒" 模拟，但可靠性低） |
5. 高可用与故障恢复：无状态重启 vs 分区重选
Pulsar 的无状态 Broker 让故障恢复更高效。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| Broker 故障 | Broker 无状态，故障后：- 协调层（ZooKeeper）快速检测到故障- 其他 Broker 自动接管其负责的 Topic（无需迁移数据）- 恢复时间通常 < 10 秒 | Broker 有状态，故障后：- 需等待分区副本重新选举 Leader（如 30-60 秒，取决于配置）- 若故障 Broker 是 Leader，需 Follower 升级为 Leader- 数据可能存在短暂不可用 |
| 存储节点故障 | Bookie 故障后：- 消息条目有 N 个副本，其他 Bookie 可继续提供数据- 故障 Bookie 重启后自动同步缺失数据- 不影响 Broker 服务 | Broker 存储故障后：- 若故障 Broker 是分区 Leader，需等待 Follower 选举- 若所有副本均故障，数据永久丢失- 恢复依赖副本同步，耗时较长 |
6. 运维复杂度：无状态易管理 vs 有状态需谨慎
Pulsar 的架构设计降低了运维成本，尤其是 Broker 层面。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| 节点运维 | - Broker 无状态：重启 / 升级不影响数据，可滚动更新- BookKeeper 运维较复杂（需管理 Ledger 生命周期） | - Broker 有状态：重启 / 升级需先迁移分区，避免数据丢失- 分区迁移、日志清理、压缩需手动监控，否则易引发性能问题 |
| 监控与告警 | 提供统一监控指标（Broker + BookKeeper + 配置存储），支持 Prometheus/Grafana 集成 | 需分别监控 Broker、ZooKeeper、分区副本、消费组 Offset，指标分散 |
| 版本升级 | Broker 可独立升级（无状态），BookKeeper 支持滚动升级（不中断服务） | 升级需谨慎：- 需保证集群版本兼容（如先升级 Follower 再升级 Leader）- 跨大版本升级可能需迁移数据 |
7. 生态与兼容性
Kafka 生态更成熟，Pulsar 兼容 Kafka 客户端以降低迁移成本。
| 维度 | Apache Pulsar | Apache Kafka |
|---|---|---|
| 生态成熟度 | 生态较新，但增长快：- 支持 Flink、Spark Streaming 等计算框架- 提供 Pulsar IO（连接器）、Pulsar SQL（查询消息） | 生态极成熟：- 几乎所有流计算框架（Flink、Spark、Flink CDC）均优先支持 Kafka- 连接器丰富（如数据库、消息队列、存储系统）- 社区文档和案例更多 |
| 兼容性 | 原生兼容 Kafka 0.9+ 客户端：- 只需修改服务地址，Kafka 客户端可直接连接 Pulsar- 支持 Kafka 主题、消费组、Offset 格式 | 仅支持自身客户端，不兼容 Pulsar 客户端（需修改代码迁移） |
三、总结：如何选择？
| 场景需求 | 优先选择 Apache Pulsar | 优先选择 Apache Kafka |
|---|---|---|
| 运维简单性 | ✅ 无状态 Broker，扩容 / 升级不影响数据 | ❌ 有状态 Broker，需管理分区迁移和日志清理 |
| 跨地域复制 | ✅ 原生 Geo-Replication，配置简单 | ❌ 依赖 MirrorMaker，复杂度高 |
| 多租户 / 资源隔离 | ✅ 原生多租户，支持配额管理 | ❌ 需模拟实现，资源隔离弱 |
| 灵活消费模式 | ✅ 支持共享、故障转移等多模式，适配多业务场景 | ❌ 仅消费组模式，灵活度低 |
| 现有 Kafka 生态依赖 | ❌ 虽兼容客户端，但生态集成不如原生 | ✅ 生态成熟，无需修改现有系统 |
| 极致吞吐需求 | ✅ 计算存储分离，BookKeeper 优化顺序写入，吞吐稳定 | ✅ 分区日志优化顺序读写，吞吐极高（但存储扩容受限） |
核心架构差异回顾
| 对比维度 | Pulsar 核心特征 | Kafka 核心特征 |
|---|---|---|
| 架构理念 | 计算（Broker）与存储（BookKeeper）分离 | 计算与存储耦合（Broker 存消息） |
| 存储抽象 | Managed Ledger + BookKeeper Ledger | 分区 Log Segment |
| Broker 状态 | 无状态（不存数据） | 有状态（存分区日志） |
| 扩容方式 | Broker 即插即用，BookKeeper 线性扩展 | 分区迁移，存储扩容复杂 |
| 跨集群复制 | 原生支持 Geo-Replication | 依赖 MirrorMaker 工具 |