Apache Pulsar 在腾讯计费场景下的应用

腾讯计费平台

腾讯计费（米大师）是孵化于支撑腾讯内部业务千亿级营收的互联网计费平台，汇集国内外主流支付渠道，提供账户管理、精准营销、安全风控、稽核分账、计费分析等多维度服务。平台承载了公司每天数亿收入大盘，为 180+ 个国家（地区）、万级业务代码、100W+ 结算商户提供服务，托管账户总量 300 多亿，是一个全方位的一站式计费平台。

腾讯计费的核心痛点

在体量如此庞大的腾讯计费场景下，我们要解决的核心问题就是如何确保钱货一致。腾讯计费自研了分布式交易引擎 TDXA，这是一套交易控制解决框架方案，致力于解决交易过程中应用层逻辑一致性问题。从业界现状看，TDXA 也是少有的专注于应用层的交易事务解决方案提供者，整体架构如下：

TM：分布式事务管理器。作为 TDXA 的控制大脑，采用去中心化模式，提供高可用服务，支持纯接口调用的 TCC 以及 DB 混合事务。在执行效率方面借助协程异步框架 TDF 以及 TDSQL 异步事务（Prepare 后可以关闭链接）能力支撑全公司的计费业务。
CM：作为 TDXA 的配置中心，引入可灵活注册的跳转控制机制，即时构建事务流程有向图，可以自动对流程的正确性和完备性进行检查，并以图形界面展示给用户，在图形界面进行管理。
TDSQL：自研金融级分布式数据库，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，为用户提供完整的分布式数据库解决方案。
MQ：为 TDXA 提供高一致、高可用的消息通道能力，结合事物状态表最终对各种异常进行收敛。

MQ 在计费场景的应用

围绕计费高一致目标，MQ（message queue）在腾讯计费中的应用可以分为在线服务和离线准实时服务。

在线服务场景

失败和超时，腾讯计费覆盖 80+ 特点各异的渠道，300+ 不同业务逻辑，单个支付逻辑常横跨众多不同的内外部系统，调用链路比较长，异常出现的概率相对也会比较大，特别是网络超时（比如海外支付业务）。

TDXA 在处理这类情况会配合本地事务状态库，通过消息队列、消息到期重发，从断点开始继续执行整个交易事务，保证每日亿级交易请求的一致性。

离线准实时服务场景

怎么证明计费系统的高一致呢？那就必须通过第三方对账系统来验证，对账时间粒度越小，就能越早发现问题。在互联网移动支付行业，用户体验是第一位，倘若在玩王者荣耀时，购买英雄后没有及时发货，势必会影响用户体验，甚至遭到投诉。

借助 MQ 实时管理能力以及流式计算框架对计费流水进行实时对账和监控，与 TDXA 相辅相成，共同保证整个交易的时效性和一致性。

其它场景

当遇到王者荣耀周年庆活动时，交易请求会突发 10 倍以上的流量增长。借助 MQ 削峰填谷的能力，交易流水查询和推送以及 Tips 通知等场景能够顶住洪峰压力。

同时，在付费用户画像场景对用户行为数据进行实时挖掘分析，能为业务提供更智能的营销服务。

为什么选择 Pulsar

腾讯计费系统对分布式消息队列的要求如下：

一致性要求：计费场景要求数据一条不能丢，这是最基本的诉求。
高可用要求：需具备容灾能力，在异常情况下能够自动修复。
海量存储需求：在移动互联网时代，产生大量的交易数据，需要具备海量堆积能力。
快速响应要求：在亿级支付场景下，要求 MQ 能提供平滑的响应时间，尽可能控制在 10ms 内。

目前业界使用比较多的是 Kafka，主要场景是大数据日志处理，较少用于金融场景。RocketMQ 对 Topic 运营不太友好，特别是不支持按 Topic 删除失效消息，以及不具备宕机 Failover 能力。我们选 Pulsar 是因为其原生的高一致性，基于 BookKeeper 提供高可用存储服务，采用了存储和服务分离架构方便扩容，同时还支持多种消费模式和多域部署模式。Kafka、RocketMQ 和 Pulsar 的对比如下：

对 Pulsar 的功能优化

Pulsar 的开源生态为开发者提供了广阔、灵活的开发空间，为了在腾讯计费场景中更好地应用 Pulsar，我们对 Pulsar 做了一些功能优化：

支持延迟消息和定时重试（2.4.0 支持）。
支持二级 Tag。
完善控制台，支持消息查询和消费追踪。
完善的监控和告警体系。

延迟消息

在计费场景中，延迟消息是比较常见的需求，比如交易引擎中超时处理，又或者团购砍价活动等。

对于失败超时重试场景，并不需要在短时间内大量重试，因为很可能还是失败，依次扩大时间间隔进行重试是比较合理的。采用 Delay Topic，定时对每个队列的头部进行到期时间检查，高效地把消息投递出去，理论上可以支撑无限大的延迟消息。

Delay Topic 基本上能满足绝大部分场景，也有少数其它场景需要指定任意延迟时间。采用 Time wheel 的方式可精确到秒，但需要维护索引关系，不太适合大规模的延迟消息。

在不改变 Pulsar 内部存储模式的前提下，我们支持这两种模式，支撑了王者荣耀英雄砍价活动。

二级 Tag

腾讯计费有上万个业务代码，为了提高安全性，需要按业务同步交易流水。如果按业务代码创建 Topic，需要创建上万个 Topic, 这样会增加管理 Topic 的负担；如果一个消费者需要消费交易流水的所有业务，则需要维护上万个订阅关系。

我们在消息元数据中加入 Tag 属性，用户在生产消息时可设定多个 Tag ，消费时 broker 端会过滤掉不匹配的 Tag。

控制台

消息队列在线上大规模使用需要具备一个完善的控制台。用户经常会问以下几个问题：

这条消息的内容是什么？
这条消息的生产者是谁？
这条消息被消费了吗？消费者是谁？

针对于这几个问题，我们对消息的整个生命周期（即从消息产生到消息被消费）进行追踪。

我们对 Pulsar 消息元数据加入生命周期相关数据(由于消费时间和消费地址不是消息本身的属性，因此不能将它们直接加在消息元数据中，但可以通过 ES 中流水日志关联查询到它们的信息），再注册 Topic、生产组、订阅关系以及权限，提供统一接入流程管理。

监控告警

我们在 Pulsar 中加入系统监控数据采集组件，数据最终对接计费平台部的鹰眼运营平台，可以自定义告警规则，按业务秒级精准告警。如有临时突发情况，鹰眼平台会根据当前负载情况生成扩容方案，并支持一键扩容。

告警有以下类型：

积压告警：在线服务中，如果出现大量消息堆积，说明后端消费成为瓶颈。此时需要及时告警，通知相关人员进行处理。
延迟告警：在交易记录查询场景中，要求购买记录在 1 秒内查出。撮合监控组件采集的生产流水和消费流水，能统计出每条消息生命周期。
失败告警：常规统计流水中的错误信息，从业务、IP 等多维度进行监控告警。

总体架构

如前文所述，腾讯计费优化了 Pulsar 四大模块的功能，由此搭建了以下架构：

Broker 作为消息队列代理层，负责消息的生产和消费请求，支持水平扩展，根据负载按 Topic 自动进行均衡。
BookKeeper 作为消息队列的分布式存储中心，可配置多个消息副本，在异常情况下具备 Failover 能力。
ZooKeeper 作为消息队列的元数据和集群配置中心。
支持多种消费模式，其中 Shared 模式下的消费者突破对分区个数的依赖， function 模式非常适合简单的交易流水清洗场景。
提供了统一的 HTTP proxy 接入能力，方便其它语言接入。
腾讯计费还有部分业务是 JS 和 PHP 等语言，提供了统一的 HTTP proxy 接入能力，并对客户端加上生产失败重试能力，提升生产成功率。集群出现异常时，客户端会做降级处理，将消息发送至本地或发送至容灾集群。

以上是我们对 Pulsar 所做的功能优化。我们会继续和 Apache Pulsar 社区合作，把这些优化的功能贡献给社区，希望帮助到社区的其他用户。我们也希望更多的用户加入 Pulsar 社区，共同完善 Pulsar 功能。