导语

本文整理自 8 月 Apache Pulsar Meetup 上，刘燊题为《Apache Pulsar 在微信的大流量实时推荐场景实践》的分享。本文介绍了微信团队在大流量场景下将 Pulsar 部署在 K8s 上的实践与优化、非持久化 Topic 的应用、负载均衡与 Broker 缓存优化实践与COS Offloader 开发与应用。

作者简介

刘燊，腾讯微信高级研发工程师，Apache Pulsar Contributor。

在通信社交领域，微信已经成为国内当之无愧的社交霸主。用户人数在 2018 年突破了 10 亿，截至 2021 年第三季度末，微信每月活动账户总数已达到 12.6 亿人，可以说，微信已经成为国人生活的一部分。

微信的业务场景包括推荐业务、风控、监控系统、AI 平台等。数据通过 SDK 和数据采集方式接入，经由 MQ、Kafka、Pulsar 消息中间件，其中 Pulsar 发挥了很大的作用。中间件下游接入数据计算层 Hadoop、Spark、Flink、ClickHouse、TensorFlow 等计算平台，由于本次介绍实时推荐场景，因此较多使用 Flink 和 TensorFlow。落地存储平台则包括 HDFS、HBase、Redis 以及各类自研 KV。

团队选型 Pulsar 的初期目标是获得一个满足大数据流量场景并且运维管理便捷的消息队列系统。最终选择 Pulsar 的主要原因有五点：  

• 在腾讯自研上云的大背景下，团队非常看重云原生特性。Pulsar 的云原生特性，包括分布式、弹性伸缩、读写分离等都体现出优势。Pulsar 逻辑层 Broker 无状态，直接提供服务。存储层 Bookie 有状态，但是节点对等，且 Bookie 自带多副本容灾；
• Pulsar 支持资源隔离，可以软隔离或硬隔离，避免不同业务之间互相影响；
• Pulsar 支持灵活的 Namespace/Topic 策略管控，对集群的管理和维护有很大帮助；
• Pulsar 能够便捷扩容，逻辑层 Broker 的无状态和负载均衡策略允许快速扩容，存储层 Bookie 节点之间互相对等也便于快速扩容，可以轻松应对流量暴涨场景；
• Pulsar 具备多语言客户端能力，微信的业务场景中涉及 C/C++、TensorFlow、Python 等语言，Pulsar 可以满足需求。

实践 1：大流量场景下的 K8s 部署实践

微信团队使用了 Pulsar 官网提供的 K8s Helm chart 部署方式。

原生部署架构中，流量从 Proxy 代理层进入，经过 Broker 逻辑服务层写入 Bookie 存储层。Proxy 代理层代理客户端和 Broker 之间的连接，Broker 层管理 Topic，Bookie 层负责持久化消息存储。在上图中，入流量和出流量分别用 In 和 Out 进行标记，Replica 是配置的副本。

在应用的过程中团队发现了两个问题：首先 Proxy 代理了 Pulsar 客户端的请求，导致 Broker 无法获取客户端 IP，增加了运维难度；其次，当集群流量较大时，集群内部带宽会成为瓶颈。上图架构内，集群入流量为 （2+ 副本数）倍；出流量最大为 3 倍，Consumer、Proxy、Broker 和 Bookie 间分别有一倍流量，但是仅极端情况下流量会全量从 Bookie 流出。假设出入流量都是 10 GBps，副本数为 3，集群内入流量会放大为 50 GBps，出流量会放大为 30 GBps。另外默认情况下 Proxy 服务只有一个负载均衡器承载所有流量，压力巨大。

这里可以看出瓶颈主要出现在 Proxy 层，该层造成了很大流量浪费。而 Pulsar 实际上支持 Broker 直连，因此团队在此基础上进行了一些优化：

团队利用了腾讯云 K8s 集群的能力，给 Broker 配置了弹性网卡，并使 Broker 的 IP 直接暴露在集群外，可以被外部客户端直接访问。Broker 服务也配置了负载均衡器。这样客户端可以直接访问负载均衡器 IP，再经过 Pulsar 内部协议的 Lookup 操作找到要访问的 Topic 所处的 Broker。由此节省了 Proxy 带来的额外带宽消耗。

团队在 K8s 部署方面还做了以下优化工作：

• 如上文所述去 Proxy；
• Bookie 使用多盘多目录 + 本地 SSD 提升性能，由于原社区版本 Pulsar 不支持多盘多目录，这里团队做了改进支持并合并入社区(github.com/apache/puls…)；
• 日志采集使用腾讯云 CLS（日志服务），统一的日志服务可以简化分布式多节点系统的运维、问题查询操作；
• 指标采集使用 Grafana + Kvass + Thanos，默认指标采集使用了单机服务，很快出现了性能瓶颈，优化后问题解决且支持水平扩容。

实践 2：非持久化 Topic 的应用

生产者和消费者是同 Broker 中的 Dispatcher 模块交互的，而持久化 Topic 中生产者数据会通过 Dispatcher 进入 Managed Ledger 模块，再调用 Bookie 客户端与 Bookie 交互。非持久化 Topic 中数据不会进入 Managed Ledger，而是直接发送给消费者。在大流量场景中，非持久化 Topic 由于不需要与 Bookie 交互，对集群的带宽压力会明显降低。

非持久化 Topic 在大流量实时推荐场景中有应用，但具体的应用场景必须满足“可容忍少量数据丢失”的要求。实践中有三种场景满足这一要求：

• 大流量 + 消费端处理能力不足的实时训练任务；
• 时效性敏感的实时训练任务；
• 抽样评测任务。

实践 3：负载均衡与 Broker 缓存优化

以上所述是小编给大家介绍的Apache Pulsar 微信大流量实时推荐场景下实践详解,希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对77isp云服务器技术网的支持！