对于 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，正本同步）频繁稳定等。
为了解决下面这个问题，通常咱们会为每个用户部署一个集群，保障每个集群的分区数不会过多。但因为每个集群总流量不大，会造成集群资源使用率不高，有大量闲置资源，无奈施展云原生环境的劣势。
这种状况下，最现实的形式是多个用户共用一个集群的资源，别离限度资源的使用量，避免出现资源节约。但如果把所有用户全副汇集起来放在同一个集群运行，又可能会呈现几十万、上百万分区数问题，这就是咱们的第二个挑战——海量分区治理。
挑战三：无开箱即用的异地多活解决方案
很多金融级用户的业务场景对高可用、RTO（Recovery Time Objective，业务复原工夫）等指标要求十分高，因而须要同城多机房或者两地三核心的异地多活的形式。对于强统一的异地多活，现有的音讯队列很少有提供开箱即用的残缺计划。
遇见 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 形象了 Bundle 的概念。Bundle 的元数据保留在 ZooKeeper。每个分区落在哪个 Broker 上，这种关系信息不会间接保存起来。Apache Pulsar 应用一致性哈希，把 Bundle 作为哈希环中的节点，让所有的分区散列上去。咱们只需保留 Bundle 与 Broker 之间映射关系的信息即可；分区与 Bundle 之间的关系是固定的，能够通过散列动静计算出来，不须要保留每条关系。
如此一来，咱们须要存储的元数据就有几个量级的降落。在切换 Broker 时，基于一致性哈希的劣势，分区再均衡只会波及到局部变动，能够迅速从新进行调配。
Apache Pulsar 在腾讯云上的实际
通过调研后，咱们决定基于 Apache Pulsar 打造一款新的音讯队列——TDMQ，开启 Apache Pulsar 在腾讯云上的实际之路。上面和大家分享下 Apache Pulsar 在腾讯云上的实践经验，探索 Apache Pulsar 如何疾速适配云原生环境。
云原生下的平滑扩容
咱们利用 Apache Pulsar 反对云原生环境进行平滑扩容。常见的扩容场景分为几种状况：
a) 当分区数量远大于 Broker 数量时，新增 Broker，分区用一致性哈希（hash）形式主动迁徙 Topic 到新的 Broker，而后新的 Broker 就能够对外提供服务，分担压力。
b) 当分区数量少于 Broker 数量时，减少分区，让流量散布到更多 Broker 上，从而实现平滑扩容。
数据歪斜与存储层扩容
Broker 不保留数据，Broker 通过 BookKeeper Client 把数据放弃到 BookKeeper 集群中，每个节点咱们称为 Bookie。最终还是无奈防止 Bookie 是有状态的，问题又回到了原点，有状态的 Bookie 又如何实现平滑扩容呢？
首先，咱们须要理解 Apache Pulsar 的存储机制。Apache Pulsar 应用 Quorum 机制来保证数据的一致性和高可用。当 Apache Pulsar 长久化一条音讯时，Broker 应用 BookKeeper client 同时并行写入多个 Bookie 节点，依据音讯的 Ack 数，来判断有多少数据写入胜利。
- ENSEMBLE SIZE（E）：可用 Bookie 的数量
- WRITE QUORUM SIZE（QW）：并行写入音讯的 Bookie 数量
- QUORUM SIZE（QA）：Ack 音讯的数量
如果 Bookie 的数量大于 QW 的值，数据会以条带化的形式落到不同节点上，过程如下图所示：
- 第一条音讯，Broker 会同时写入 Bookie1、Bookie2、Bookie3。
- 第二条音讯，Broker 会同时写入 Bookie2、Bookie3、Bookie4。
- 第三条音讯，Broker 会同时写入 Bookie3、Bookie4、Bookie5。
- 第四条音讯，Broker 会同时写入 Bookie4、Bookie5、Bookie6。
…
这种条带化写入的益处不言而喻，既能充分利用每个磁盘上的 IO，还能让数据存储近似平均，避免出现数据歪斜问题。当减少新 Bookie 节点后，无需期待数据迁徙就能够对外提供服务，整个过程十分平滑。
海量分区：升高和去除 ZK 依赖
海量分区是咱们要解决的一个重要问题。如上所述，Apache Pulsar 形象的 Bundle 的概念能很好地帮忙咱们解决上云过程中遇到的海量分区治理问题。但 ledger、cursor 等其余元数据还是存储在 ZooKeeper 中。当分区数量达到百万时，ZooKeeper 会不堪重负。因而，咱们基于 Apache Pulsar 做了一些改良——升高和去除 Broker 对 ZooKeeper 的依赖。
Apache Pulsar Broker 对 ZooKeeper 的依赖次要包含以下几个方面：
- 负载情况
- 生产、生产
- Policy 存储
- Leader 节点选举
通过对依赖的剖析和梳理，咱们确定了升高和去除对 ZooKeeper 依赖的两步指标：
a. 升高 Broker 对 ZooKeeper 的依赖。即便 ZooKeeper 挂掉了，Broker 至多在一段时间内不会受到很大的影响，能够持续提供读写服务，期待 ZooKeeper 的复原。
b. 齐全去除对 ZooKeeper 的依赖。将元数据全副保留到 Bookie，不再依赖 ZooKeeper 存储数据。
具体地，咱们对代码做了一些改变，如：
- 在 ZooKeeper 挂掉、本地缓存超时的状况下，让本地的缓存快照不过期，Broker 放弃以后元数据不变，持续应用缓存中的元数据。
- 在写入过程中，如果 Ledger 承载的 entry 数量曾经超过了限度的大小，Apache Pulsar 会敞开以后 Ledger 并重开一个 Ledger。咱们优化后，在这种状况下，Broker 临时不敞开以后 Ledger，而是持续写入，从而防止拜访 ZooKeeper。
- 应用内部存储保留负载情况等数据。
- 只在启动时依赖 ZooKeeper 选举 Leader 节点，后续则通过订阅的 Exclusive 个性实现选主。
加强原生异地复制能力，提供强统一计划
有些用户的业务场景对高可用的要求十分高，须要同城多机房或者两地三核心的异地多活。Apache Pulsar 自身有相应的异地复制能力，但属于异步复制。异步复制就要看用户对 RTO、RPO（Recovery Point Objective，复原点指标）的容忍水平，如果要求 100% 牢靠，一条音讯都不能丢，那异步复制不能满足要求。
另外，异步复制即便为全量复制，为了保障音讯程序，同一时间咱们通常只会应用一个核心，这样整体资源利用率最多为 50%，资源使用率不高。另外，无奈保障灾备核心何时能接管流量，接管后所有业务是否失常运行。因而，咱们提供了强统一的计划。
1. 同城跨机房
Broker 跨机房。多数据中心之间位置均等。失常模式下，多数据中心协同工作，并行为业务提供拜访服务，充分利用资源。一个数据中心产生故障或劫难，其余数据中心失常运行，立刻对要害业务或者全副业务实现接管，达到互备成果，使下层业务不会有显著的感知。
2. 三核心高可用
跨地区场景，分为生产核心、同城容灾核心、异地容灾核心。当双核心因为自然灾害等起因而产生故障时，异地灾备核心能够用备份数据恢复业务。
无论是同城跨机房还是三核心的高可用，对写入都有限度——限度每条音讯必须要跨机房 / 地区写入，Ack 胜利才算胜利。
此外，咱们实现了主动无感知切换模式。如果找不到相应的备份地区，主动通过模式切换进行降级，使用户能够在单个区域外面持续写入、生产、生产，实现无感知切换。
Apache Pulsar 具备跨机架、跨区域感知的能力，云上的经营端配合 Broker 中bookkeeperClientRackawarePolicyEnabled、bookkeeperClientRegionawarePolicyEnabled、bookkeeperClientSecondaryIsolationGroups 等参数，就能实现上述能力。
除了实现 Broker 的高可用，咱们也实现了跨机房 / 地区 ZooKeeper 的高可用。为了可能疾速复原集群，每一个数据中心的 ZooKeeper 都有 Observer。Observer 不参加投票和选举。当集群节点数有余时，Observer 可疾速切换为对应的 Follower，参加选举，保障 ZooKeeper 集群的高可用。
另外，咱们弱化了对 ZooKeeper 的依赖。即便一段时间内 ZooKeeper 不可用，Broker 还能够持续对外提供服务，弱化下层业务对切换的感知。
因为地区之间网络提早，保障强一致性跨地区容灾，会让下层业务应用音讯队列的提早回升，因而须要业务方依据本身的理论状况，衡量抉择具体的异地多活形式。
将来寄语
绝对于其余传统音讯队列，Apache Pulsar 借助存储与计算拆散的云原生架构，以及撑持平滑迁徙、承载海量分区、跨区域数据复制等原生性能个性，成为解决原有音讯队列上云挑战的最佳解决方案之一，目前一直吸引泛滥国内外企业落地并汇集了泛滥沉闷开发者。但以后 Apache Pulsar 间隔最终的 Serverless 化、无规格化、有限流量等愿景指标还有一段路要走，这也正是 Apache Pulsar 社区泛滥贡献者的价值所在，期待大家可能参加进来。咱们会持续踊跃和社区单干，一起欠缺 Apache Pulsar 生态。
云原生是正在产生的重要技术事实，云原生落地之路也刚刚开始，期待通过丰盛的场景和实际，继续推动云原生后退。心愿上述咱们在音讯队列方向的摸索与实际可能带给有着相似需要的同行一些参考。
在腾讯云上，咱们基于 Apache Pulsar 推出了 TDMQ 音讯队列，除了上述改变，还有其余新个性。2021 年，TDMQ 会提供更多的新个性，反对 HTTP、AMQP 等多种协定，方便使用其余音讯队列的用户无缝迁徙到腾讯云上。同时，咱们还会有更多加强能力，如 Function、金融级 SLA 承诺、寰球音讯同步、Serverless Topic、弹性用量等等。
作者简介：
林琳，Apache Pulsar PMC 成员、腾讯云专家工程师，专一于中间件畛域，在音讯队列和微服务方向具
有丰盛的教训。