消息队列上云挑战与方案：腾讯云的 Apache Pulsar 实践

关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。GitHub 地址：http://github.com/apache/pulsar/

以下文章首发自公众号 InfoQ，作者林琳。

导读：云原生大潮风起云涌，企业不再停留在理念层面，目前已在多方面落地。消息队列作为关键技术基础设施之一，也在云原生时代面临着挑战和机会。本文从传统消息队列上云所面临的三大挑战说起，并以 Apache Pulsar 为技术案例，深入浅出地讲解了如何打造适配云原生的消息队列。希望本文能对大家提供参考。

背景介绍

如今，云原生的概念已经渗透到了软件开发的方方面面。云原生不再只是未来的设想，而是一个现在进行时。开发人员在开发设计之初就需要考虑未来如何在云原生环境上部署、运行服务，即如何“上云”。

在云上，消息队列将成为一种基础设施，像自来水一样，可以随时按需使用，并且有无限容量。用户无需关心消息队列的型号、规格，或是否需要升级配置，只需专注上层业务。

腾讯云是腾讯集团倾力打造的云计算品牌，面向全世界各个国家和地区的政府机构、企业组织和个人开发者，提供全球领先的云计算、大数据、人工智能等技术产品与服务，助力各行各业实现数字化升级。为了更好地为广大用户服务，提供金融级可靠消息服务，腾讯云开启了消息队列上云之路，目前 Apache Pulsar 在腾讯云上已经大规模使用。

传统消息队列上云遇到的挑战

消息队列在上云过程中遇到了很多新的挑战，比如如何平滑扩容、如何管理海量分区、如何保证异地多活等高可用性。

挑战一：平滑扩容能力不足

传统消息队列（如 Kafka 等），在平滑扩容方面存在很多不足，很难做到快速、无感知地扩容。由于 Kafka 的数据保存在 Broker 上，而每个 Broker 上的分区数据是有状态的，因此每个 Broker 上数据可能不同，客户不能通过简单地增加 Broker 数量完成扩容。当集群增加新 Broker 进行扩容时，会涉及数据迁移和同步，进而引发磁盘 IO 和网络消耗。当流量突然爆发，业务本身使用 IO 和网络带宽就会很高。此时，如果由于集群容量不足而触发扩容，迁移的带宽占用和数据冷读会直接影响到上层业务的使用，造成高延迟和错误率飙升。如果写入的速度比迁移速度更快，那可能永远都无法完成数据迁移。

此外，通常 20% 的客户占用了 80% 的流量，有些用户对底层消息队列并不熟悉，使用方式可能不规范，导致 Broker 端出现数据倾斜，很容易造成某些节点的磁盘占满，而其他节点的磁盘有比较大的空间。只采用简单扩容、迁移数据的方式根本无法解决这种情况。

挑战二：海量分区管理无法承载

有些用户的业务比较特殊，单个分区的流量不大，但总体使用的分区数很多。现有的一些消息队列，很难承载海量的分区，例如：如果一个 Kafka 集群分区数太多，当出现 Leader 或者 Controller 切换时，恢复时间会很长。另外，如果不使用 SSD，文件写入变得分散，可能出现复制跟不上，导致 ISR（In-Sync Replicas，副本同步）频繁波动等。

为了解决上面这个问题，通常我们会为每个用户部署一个集群，保证每个集群的分区数不会过多。但由于每个集群总流量不大&#x