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

消息队列上云挑战与方案：腾讯云的 Apache Pulsar 实践 如今，云原生的概念已经渗透到了软件开发的方方面面。云原生不再只是将来的设想，而是一个现在进行时。开发人员在开发设计之初就需要考虑将来如何在云原生环境上部署、运转服务，即如何“上云”。 在云上，消息队列将成为一种基础设备，像自来水一样，可以随时按需使用，并且有无限容量。用户无需关怀消息队列的型号、规格，或能否需要升级配置，只需专注上层业务。 腾讯云是腾讯集团倾力打造的云计算品牌，面对全世界各个国家和地区的政府机构、企业组织和个人开发者，供应全球领先的云计算、大数据、人工智能等技术产品与服务，助力各行各业实现数字化升级。为了更好地为宽敞用户服务，供应金融级牢靠消息服务，腾讯云开启了消息队列上云之路，目前 Apache Pulsar 在腾讯云上已经大规模使用。 2 传统消息队列上云遇到的挑战 消息队列在上云过程中遇到了很多新的挑战，比如如何平滑扩容、如何管理海量分区、如何保证异地多活等高可用性。 挑战一：平滑扩容力量不足 传统消息队列（如 Kafka 等），在平滑扩容方面存在很多不足，很难做到快速、无感知地扩容。由于 Kafka 的数据保存在 Broker 上，而每个 Broker 上的分区数据是无形态的，因而每个 Broker 上数据可能不同，客户不能通过简约地添加 Broker 数量完成扩容。当集群添加新 Broker 进行扩容时，会涉及数据迁移和同步，进而引发磁盘 IO 和网络消耗。当流量突然迸发，业务本身使用 IO 和网络带宽就会很高。此时，假如由于集群容量不足而触发扩容，迁移的带宽占用和数据冷读会直接影响到上层业务的使用，形成高延迟和错误率飙升。假如写入的速度比迁移速度更快，那可能永久都无法完成数据迁移。 此外，通常 20% 的客户占用了 80% 的流量，有些用户对底层消息队列并不生疏，使用方式可能不规范，导致 Broker 端消灭数据倾斜，很简约形成某些节点的磁盘占满，而其他节点的磁盘有比较大的空间。只接受简约扩容、迁移数据的方式根本无法处理这种情况。 挑战二：海量分区管理无法承载 有些用户的业务比较特殊，单个分区的流量不大，但总体使用的分区数很多。现有的一些消息队列，很难承载海量的分区，例如：假如一个 Kafka 集群分区数太多，当消灭 Leader 或者 Controller 切换时，恢复时间会很长。另外，假如不使用 SSD，文件写入变得分散，可能消灭复制跟不上，导致 ISR（In-Sync Replicas，副本同步）频繁波动等。 为了处理上面这个问题，通常我们会为每个用户部署一个集群，保证每个集群的分区数不会过多。但由于每个集群总流量不大，会形成集群资源使用率不高，有大量闲置资源，无法发挥云原生环境的优势。 这种情况下，最抱负的方式是多个用户共用一个集群的资源，分别限制资源的使用量，避开消灭资源铺张。但假如把全部用户全部聚集起来放在同一个集群运转，又可能会消灭几十万、上百万分区数问题，这就是我们的其次个挑战——海量分区管理。 挑战三：无开箱即用的异地多活处理方案 很多金融级用户的业务场景对高可用、RTO（Recovery Time Objective，业务恢复时间）等目标要求格外高，因而需要同城多机房或者两地三中心的异地多活的方式。对于强全都的异地多活，现有的消息队列很少有供应开箱即用的完整方案。 3 遇见 Apache Pulsar 假如使用传统的消息队列上云，要处理上述问题需要费一番功夫。通过调研，我们发觉为云原生打造的下一代分布式消息系统 Apache Pulsar 能很好地处理上述的大部分问题。下面针对上述各种挑战，我们从 Apache Pulsar 具备的力量做下针对性概述。 支持秒级平滑扩容 Apache Pulsar 支持云原生环境，可以充分利用云原生环境的弹性力量，达到自动、无感知的扩容，按需使用，不影响上层业务。Apache Pulsar 使用 BookKeeper 作为数据存储层，而 BookKeeper 原生避开数据倾斜问题。 Apache Pulsar 上层 Broker 无形态，原生支持平滑扩容。当流量突发添加时，只需要添加一个 Broker，然后等待部分 Topic 重新安排到新的 Broker 上，流量就会自动迁移到新的 Broker 上。整个过程只涉及元数据的修改和 Topic 安排的计算，实现秒级自动迁移。 具备海量分区支撑力量 在云上，海量分区是常见问题。假设客户有 100 万个分区，假如把每个分区的元数据信息都保存起来，那总体数据量会有几百 MB，光是下载这么多的数据都需要很多时间。 Apache Pulsar 没有完全处理全部问题，但已经具备支持海量分区的力量。Apache Pulsar 笼统了 Bundl