Kafka 方案及其痛点
之前，我们采用 Apache Kafka 作为消息平台， 为了让业务在高峰期（晚上八点到十点）不受影响，我们根据消息业务量的大小， 分别搭建了不同的集群。对于一些业务场景的需求， 比如需要重置 offset 来消费过去几天的消息，使用 Kafka 需要停掉消费者才可以进行， 这种方式对大量在线业务非常不利，只能采用重写消息或者一些不太灵活的方式来实现， 极大降低了使用体验。
- Kafka 没有租户概念，需要手动维护多个集群，不方便运维。
- Kafka 集群扩容后需要做 Reassign Partitions，IO 消耗大。
- Kafka 监控体系不完善，排查问题较为繁琐。
- 在线业务消息重置不方便，实现起来较为麻烦，需要停掉消费组。
- Kafka 不支持死信队列和延迟队列。
- Kafka 没有官方维护和支持的 Go 语言客户端。
- 在 Kafka 中支持 schema，需要引入额外组件，不方便维护。
挑战
最初，BIGO 的消息流平台主要采用开源 Kafka 作为数据支撑。随着数据规模日益增长，产品不断迭代，BIGO 消息流平台承载的数据规模出现了成倍增长，下游的在线模型训练、在线推荐、实时数据分析、实时数仓等业务对消息流平台的实时性和稳定性提出了更高的要求。开源的 Kafka 集群难以支撑海量数据处理场景，我们需要投入更多的人力去维护多个 Kafka 集群，这样成本会越来越高，主要体现在以下几个方面：
•数据存储和消息队列服务绑定，集群扩缩容/分区均衡需要大量拷贝数据，造成集群性能下降。•当分区副本不处于 ISR（同步）状态时，一旦有 broker 发生故障，可能会造成数据丢失或该分区无法提供读写服务。•当 Kafka broker 磁盘故障/空间占用率过高时，需要进行人工干预。•集群跨区域同步使用 KMM（Kafka Mirror Maker），性能和稳定性难以达到预期。•在 catch-up 读场景下，容易出现 PageCache 污染，造成读写性能下降。•Kafka broker 上存储的 topic 分区数量有限，分区数越多，磁盘读写顺序性越差，读写性能越低。•Kafka 集群规模增长导致运维成本急剧增长，需要投入大量的人力进行日常运维；在 BIGO，扩容一台机器到 Kafka 集群并进行分区均衡，需要 0.5 人/天；缩容一台机器需要 1 人/天。
如果继续使用 Kafka，成本会不断上升：扩缩容机器、增加运维人力。同时，随着业务规模增长，我们对消息系统有了更高的要求：系统要更稳定可靠、便于水平扩展、延迟低。为了提高消息队列的实时性、稳定性和可靠性，降低运维成本，我们开始考虑是否要基于开源 Kafka 做本地化二次开发，或者看看社区中有没有更好的解决方案，来解决我们在维护 Kafka 集群时遇到的问题。
为什么选择 Pulsar
2019 年 11 月，我们开始调研消息队列，对比当前主流消息流平台的优缺点，并跟我们的需求对接。在调研过程中，我们发现 Apache Pulsar 是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体。Pulsar 能够无缝扩容、延迟低、吞吐高，支持多租户和跨地域复制。最重要的是，Pulsar 存储、计算分离的架构能够完美解决 Kafka 扩缩容的问题。Pulsar producer 把消息发送给 broker，broker 通过 bookie client 写到第二层的存储 BookKeeper 上。
