背景

Midas是一个支持腾讯业务处理其千亿收入的计费平台。 整合国内外支付渠道，提供账户管理、精准营销、安全风控、审计核算、计费分析等多种服务。 该平台每天带来数亿美元的收入。 为180+个国家（地区）、10000+家企业和超过100万定居者提供服务。 作为全方位的一站式计费平台，其托管账户总数超过300亿。

在 Midas 中，最关键的挑战是确保事务中的数据一致性。 我们开发了一个分布式事务引擎 TDXA 来应对挑战。 TDXA 是一个分布式事务框架，旨在解决应用层的一致性问题。 TDXA 的架构如下。

主要组件描述如下。

• 一个分布式事务管理器。 作为 TDXA 的控制中心，它采用分散的方法来提供高可用性服务。 TM 支持基于 REST API 的“Try-Confirm/Cancel (TCC)”和混合数据库事务。 借助TDF（一个异步协程框架）和TDSQL中的异步事务处理，TM能够高效地支持整个公司的计费业务。
• CM: TDXA 的配置中心。 CM 提供了一种灵活的机制来在运行时注册、管理和更新事务处理流程。 它会自动检查交易流程的正确性和完整性，并在 GUI 控制台中为用户可视化。 用户可以在 GUI 控制台中管理流程。
• TDSQL: 分布式事务型数据库，具有强一致性、高可用性、全局部署架构、分布式横向扩展、高性能、企业级安全支持等特点。 TDSQL 提供了一个全面的分布式数据库解决方案。
• MQ: 需要一个高度一致且可用的消息队列，使 TDXA 能够处理事务处理过程中的各种故障。

如您所见，高度一致且可用的消息队列在处理我们的计费服务的事务中起着关键的作用。

计费服务中的消息队列

在我们的计费服务中，消息队列的使用可以分为两类：在线事务处理和实时数据处理。

Online transaction processing

Midas内部有80多个不同特性的通道，300多个不同的业务处理逻辑。 一个单一的支付工作流程通常涉及许多内部和外部系统。 这会导致更长的 RPC 链和更多的故障，尤其是网络超时（例如与海外支付服务交互时）。

TDXA 利用消息队列以可靠的方式处理事务处理中发生的故障。 与本地事务状态相结合，TDXA 能够从失败中恢复事务过程，并确保每天数十亿笔事务的一致性。

实时数据处理

计费平台的第二个挑战是，如何证明交易的数据一致性？ 我们使用对账系统对其进行验证。 协调时间越短，越早发现问题。 对于移动支付，实时用户体验至关重要。 比如在《王者荣耀》(https://en.wikipedia.org/wiki/Wangzhe_Rongyao)游戏中购买英雄后，如果没有及时发货，势必会影响用户体验，从而引发投诉。

我们通过使用流计算引擎处理消息队列中产生的交易来实时协调计费交易。

TDXA 在在线事务处理和实时数据处理中都利用消息队列来确保事务的有效性和一致性。

其他场景

在 peek 期间（例如王者荣耀周年庆活动），Midas 的交易流量可以达到平均水平的 10 倍以上。 消息队列能够缓冲这种peek流量，以减轻核心事务系统对事务查询、投递和提示通知等请求的压力。

此外，通过实时处理消息队列中的消息，我们能够为客户提供实时数据分析和精准营销服务。

为什么选择 Apache Pulsar

我们的计费平台对分布式消息队列的需求总结如下：

• Strong consistency: 计费服务不丢失数据，这是基本要求。
• High availability: 必须具备故障转移能力，并能对故障进行自动恢复。
• Massive storage: 移动应用产生大量交易数据，需要海量存储容量。
• Low latency: 处理数十亿笔交易的支付服务需要以可预测的低延迟（小于 10 毫秒）接收消息。

我们为 Midas 评估了许多开源解决方案。 Kafka 在日志收集和处理方面很流行，但由于其数据一致性和持久性问题，它很少用于关键任务的金融用例。 RocketMQ 没有提供用户友好的主题管理 API（例如不能删除每个主题的无效消息），并且在其开源版本中不提供故障转移能力。 我们评估并选择了 Pulsar，因为它具有原生的高一致性。 Apache Pulsar 基于 Apache Bookkeeper 提供高可用的存储服务，并部署了解耦架构，存储层和处理层可以独立扩展。 Pulsar 还支持多种消费模式和地理复制。

以下是我们对 Kafka、RocketMQ 和 Pulsar 的对比总结。

采用 Pulsar

在腾讯采用 Pulsar 的过程中，为了满足我们的要求，我们对 Pulsar 做了一些改动。 变化总结如下。

1.支持延迟消息和延迟重试（2.4.0版本支持）。 2.支持二级标签。 3.完善管理控制台，支持消息查询和消费跟踪。 4.完善监控预警系统。

延迟消息传递

延迟消息传递是计费服务中的常见要求。 例如，它可以用于处理事务处理中的超时。 对于服务失败或超时，不需要在短时间内多次重试事务，因为它很可能再次失败。 通过利用 Pulsar 中延迟的消息传递以退避方式重试更有意义。

延迟消息传递可以用两种不同的方法来实现。 一种是根据延迟时间间隔将消息分离到不同的主题中，并且代理会根据它们的时间间隔定期检查这些延迟主题并相应地传递延迟的消息。

这种方法可以满足大多数要求，除非您想指定任意延迟。 第二种方法是使用时间轮实现的，它可以支持以秒为单位的延迟交付。 但是这种方法必须为时间轮维护一个索引，这不适合大量延迟消息。

在保持 Pulsar 内部存储不变的情况下，我们实现了以上两种方式来支持王者荣耀游戏的讨价还价活动。

二级标签

Midas 拥有数以万计的企业。 为了提高安全性，需要根据业务同步交易流。 如果按业务创建主题，则需要创建上万个主题，增加主题管理的负担； 如果消费者需要消费来自交易流中所有业务的消息，Midas 必须维护数以万计的订阅。

因此，我们在 Pulsar 消息元数据中引入了一个 Tag 属性。 用户可以在生成消息时在消息中设置多个标签。 当消息被消费时，代理将过滤掉所需的标签。

管理控制台

要大规模使用消息队列，需要一个好的管理控制台。 管理控制台应该能够满足我们用户的以下请求。

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

为了满足这些请求，我们将生命周期相关信息添加到 Pulsar 消息元数据中。 所以我们可以跟踪消息的整个生命周期（从生产到消费）。

监控和报警

我们从 Pulsar 收集指标并将它们存储在我们的 Eagle-Eye 操作平台中。 因此，我们可以编写警报规则来监控系统。

We monitor and alert on the following metrics:

• Backlog:如果在线服务积累了海量信息，则意味着消费已经成为瓶颈。 此时，要及时报警，并通知相关人员进行处理。
• End-to-end latency: 交易记录查询场景，要求一秒内查询到购买记录。 通过匹配监控组件采集的生产流和消费流，我们可以统计每条消息的端到端延迟。
• Failures: Eagle-Eye运维平台对管道中的错误进行统计，从业务、IP等多个维度进行监控和告警。

Pulsar in Midas

通过我们在 Pulsar 中所做的增强，我们在以下架构中部署了 Pulsar。

• 作为消息队列代理层，Broker 负责消息生产和消费请求。 Broker 支持水平扩展，并根据负载按主题自动重新平衡
• BookKeeper 作为消息队列的分布式存储。 您可以在 BookKeeper 中配置消息的多个副本。 BookKeeper 在特殊情况下启用了故障转移功能。
• ZooKeeper 作为消息队列的元数据和集群配置中心。
• 一些 Midas 业务是用 JS 和 PHP 编写的。 HTTP 代理为使用其他语言的客户端提供统一的访问端点和重试能力。 当生产集群发生故障时，代理将降级并将消息路由到其他集群以进行灾难恢复。
• Pulsar 支持多种消费模式。 Shared 订阅允许将消费扩展到分区数量之外，而 Failover 订阅适用于事务清理工作流中的流处理。

我们已经成功地大规模采用并运行了 Pulsar。 在高峰期处理百亿级事务，保证处理事务的数据一致性，为我们的服务提供99.999%的高可用性。 Pulsar 的高一致性、可用性和稳定性有助于我们的计费和交易引擎高效运行。

总结

Apache Pulsar 是一个年轻的开源项目，具有吸引人的特性。 随着不同行业的新采用，Apache Pulsar 社区正在快速发展。 我们希望与 Apache Pulsar 社区开展进一步的合作，将我们的改进回馈给社区，并与其他用户一起进一步改进 Pulsar。