腾讯计费平台

腾讯计费（米大师）是孵化于支撑腾讯内部业务千亿级营收的互联网计费平台，汇集国内外主流支付渠道，提供账户管理、精准营销、安全风控、稽核分账、计费分析等多维度服务。平台承载了公司每天数亿收入大盘，为 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 做了一些功能优化：

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

延迟消息

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

对于失败超时重试场景，并不需要在短时间内大量重试，因为很可能还是失败，依次扩大时间间隔进行重试是比较合理的。采用 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 功能。

Pulsar 在腾讯计费的使用情况

分布式消息队列目前基本上覆盖了大部分计费系统，很多已经成为了支付环节的关键路径。Pulsar 稳定提供的高一致、高可用的消息通道能力，助力计费交易引擎稳定高效运转。目前，Pulsar 已在腾讯计费大规模使用，经受住了业务洪峰的压力和交易一致性的考验，达到了 5 个 9 的高可用率。

总结

Pulsar 是一个年轻的开源项目，拥有非常多吸引人的特性；Pulsar 社区发展迅猛，在不同的应用场景下不断有新的案例落地。我们会持续关注并和 Apache Pulsar 社区深入合作，把优化的功能奉献给 Pulsar 社区，和社区其他用户一起进一步完善、优化 Pulsar 的特性和功能。