Plusar是基于云上的多租户的设计，而Kafka更偏向于在系统和系统之间对接，是单租户设计，提供高吞吐。
| Pulsar | Kafka | |
|---|---|---|
| 数据集合 | Topic切分多个partitions,但一个partition只由一个broker负责读写（ownership）且一个partition均匀分散到多台bookie节点上持久化存储 | Topic切分多个partitions,各partition以目录形式在leader broker及其副本brokers 上持久化存储 |
| 租户 | 基于云的多租户设计 | 单租户、高吞吐设计 |
| 部署 | 较好适配容器化部署模式 | 以虚拟机部署为主 |
| topic量级 | 支持数百万个topic，实现不丢数据 | 无法支持量级较大topic |
| 扩容难易 | 计算与存储分享，扩容简单，业务中断时长短 | 扩容复杂 |
| 订阅模型 | 灵活支持共享订阅类型 | 只支持Failover消费模式 |
| P99延迟 | 稳定 | 波动较大 |
| 数据存储单元 | Partition->Ledges->Fragments | Partition->Segments |
| 存储节点 | BookKeeper Bookie（分散持久化到bookie,由broker内嵌的bookkepper client负责读写） | Broker (直接持久化到broker,由client SDK直接读写) |
| 读写组件 | Pulsar Broker | Client SDK |
| 数据一致性保证 | 通过多broker集群，broker Quorum Write 到bookie,返回Quorum ACK保证 | 通过多broker集群，每个partition多副本，producer指定发送确认机制保证 |
Kafka：
- 负载均衡需要人工介入：手动按异构配置的broker对应生成assignment执行计划
- 故障恢复不可控：broker重启后需复制分区新数据并重建索引，其上的读写请求转移到其他broker，流量激增场景下可能会导致集群雪崩。
- 跨数据中心备份需维护额外组件 优点：
- 生态成熟，易于Flink等现有组件集成
- 参考资料众多，有完善的官方文档和书籍
- 模型简单易上手:partition有replication,以segment和index方式存储 缺点：
- 计算与存储耦合
