客户案例分析:Airbnb - 如何分析和衡量分布式支付系统的交易完整性

最近遇到不少客户在实现交易系统微服务中遇到数据一致性问题，有的利用Redis 的分布式锁机制，有的依赖于单个关系数据库保障 ACID；但实际情况中，很多一致性依赖于非常多的自有微服务和第三方微服务，如何跟踪分析端到端的数据一致性呢？今天翻译一篇 Airbnb 团队的一篇博客分享给大家；

导读

        在分布式支付生态系统中，准确衡量和跟踪交易的端到端状态和内容以确保整个支付周期的一致性至关重要。如果没有强大的跟踪，可能会发生数据泄漏和错误，从而导致支付周期中所有各方（包括消费者，商家，网关和收单方）的收入损失或成本增加。交互式完整性很难在分布式支付系统中精确测量。由于在任何给定的交易中涉及多个系统和实体，跟踪支付状态可能是冗长的并且难以及时获得。

        借助大数据工具，Airbnb 通过各种支付状态跟踪每笔交易的内容，以确保每个支付周期都处于一致状态。 协调过程不仅可以生成数据和洞察，使团队能够跟踪和减轻意外的交易行为，还可以使系统在检测到异常时“自我修复”。

背景

        随着快速兴起的支付技术，商家在处理支付交易时面临着不断变化的环境。新的增值实体（如支付网关）的出现为商家带来了越来越大的好处，通过提供存储服务和单一API集成进行支付处理来实现简化。通过与支付网关集成，Airbnb能够通过各种处理实体在全球范围内快速扩展，而对我们的在线交易处理进行的改动极小。

        话虽这么说，与任何新的实体的整合需要付出成本。支付流程中的每个新实体都会添加一个附加层，以实现交易的完整性。事务完整性的细分可能会给生态成员带来麻烦，增加客户支持的工作量以及运营效率开销。

什么是交易一致性？

        通常，事务表示在 RDMS（关系数据库管理系统）中执行的具有原子性，一致性，隔离性和持久性的工作单元。在支付方面，交易完整性代表了一种毫无意外，准确的货币流动。金融交易的准确性可以通过各种属性来验证，例如金额，货币，状态，支付方法，甚至是及时性。

         在Airbnb，交易完整性包括内部和外部资金流动。这意味着我们不仅希望内部系统之间的支付属性完全一致，而且还要支付付款所涉及的所有外部合作伙伴。

问题描述

        Airbnb 是一个连接住客和房东的住宿平台，可以在全球范围内旅行。Airbnb 的支付是在平台上和平台外实现各方信任的关键因素。为了保障这种信任，我们必须以最准确的方式妥善处理住客和房东等团体之间的付款流程。

        Airbnb 是一个全球品牌，在190多个国家和全球 40 种货币中运营，包括难以到达且在支付生态系统中不常支持的市场。在全球范围内，存在一种单一的处理器关系，以便在全球范围内转移资金。因此，Airbnb与少数网关和数十个处理器集成，以实现全球覆盖和支付冗余。该系统包括在其系统中具有不同成熟度的处理器，不同的集成模式（API调用，批量和URL重定向）以及广泛不同的事务结算周期。例如，Airbnb支持完全同步的支付方式，例如主要的信用卡/借记卡网络，以及可能需要长达几天才能结算的支付方式，例如 Brazilian Boletos。

        对于传统的在线商家，由于在线购买，资金流入系统。然而，最近，随着共享经济的增长，我们开始看到双边市场的增加。Airbnb就是这样一个例子 - 连接世界各地的旅行者和房东。因此，Airbnb的付款处理双向资金流，不仅处理支付到我们平台的付款，还处理所有支付给房东的资金。

        流入我们平台房东的大部分资金通过批处理与银行直接集成。批处理事务涉及两个步骤。首先，我们以合规格式向银行发送一系列交易请求。然后，我们处理银行发回给我们的响应文件，其中包含对交易请求的响应。虽然批处理适用于较大的事务处理，但批处理过程本质上使我们的系统不同步，直到处理批处理响应文件。由于此过程可能需要几个小时才能完成，因此批处理可能会成为维护事务完整性的难题。

        即使在 Airbnb 交易的最简单示例中，住客和房东之间的预订，至少有两个与之相关的金融交易。第一次金融交易发生在住客向Airbnb支付预订费用时，第二次金融交易发生在 Airbnb 在提供服务的几小时内向房东付款时。但是，旅行计划的变化比我们想象的要频繁。其他付款功能，如更改，存款/分期付款，团体旅行，预扣税，增值税等都会大大增加与预订相关的金融交易的数量和复杂性。此外，Airbnb平台上的许多预订都是跨境的，涉及多种货币，这进一步增加了我们货币流动的复杂性。

AirBnb 新的支付网关

        近年来，Airbnb 的市场呈爆炸性增长，支付是扩张的关键支柱。直到最近几年，Airbnb 的大部分业务和财务交易逻辑都是在单体应用程序中执行的。

        为了提高可扩展性，Airbnb 正在沿着面向服务的体系架构进行大量投资。作为该策略的一部分，我们着手构建一个内部支付网关，以封装与各种处理器之间的所有网络通信，并处理为应用程序执行资金流动的“压力”。我们的新支付网关是一个带有专用数据存储的 Java 服务。此数据存储托管各种付款方式，并作为金融交易记录系统。

        这项新服务代表了交易完整性的两个截然不同的挑战。首先，额外的内部网关增加了支付执行期间的跳数，如果它以不一致的方式运行或无法处理网关或处理器响应，它将创建“不同步”事务。其次，当我们增加新支付网关的流量时，将有两个带有 Airbnb内部系统的交易存储 - 旧交易存储和新的支付网关交易存储。这两个挑战需要额外考虑交易完整性。

什么是“不一致”交易？

        如果支付处理链中的任何系统未能响应和/或其后续系统未能正确处理货币移动的响应，则会产生“不同步”交易。此外，处理链中任何实体对API响应的错误处理都可能导致“不同步”事务。

解决方案

        及时地测量分布式系统的迷一样交互中的事务完整性，并随后检测和响应任何异常是一项挑战。组合不同成熟度的许多系统使得几乎不可能在任何时候通过不同系统（平台，支付网关，支付处理器等）中的各种状态即时跟踪交易。

        想到的一个可能的解决方案是使用支付网关 API 进行交易记录比较。这种方法的缺点是使用 API 扩展内部事务存储和外部事务存储之间的比较更加困难。实际上，一些外部实体甚至不通过 API 提供此信息。此外，可能需要专用比较系统来执行对实体的 API 调用以进行事务分析，以避免对实时流量的任何潜在影响，这是大多数 Web服务无法容忍的场景。

AirBnb 的事务处理报告系统

        几乎所有处理器和网关都通过安全文件传输协议（SFTP）向商家提供交易报告和详细信息。这些交易报告是在商定的 SLA 内作为商家结算的一部分提供的。通常，商家通过平台交易记录，处理器结算文件和银行对账单之间的三方协调来处理平台上的所有货币移动。Airbnb拥有专门的服务，可以导入，提取和导出每个处理器文件。

详细的服务包括：

• 将我们的付款合作伙伴的每日交易报告导入S3，

• 将报告提取到特定于报告的中间表中，

• 以一致的格式导出这些报告。

        此外，它具有检测重复文件和避免重复处理同一文件的逻辑。许多处理器/网关以CSV 格式提供这些报告，并且每个实体在报告中使用自己的词汇表。然后将这些交易详细信息存储在数据存储中，并作为导出的一部分将其发送以进行对帐。

        Airbnb 的系统使用一组预定作业在专用服务器上执行这些活动。虽然该系统无法访问 Airbnb 的平台事务，但我们可以使用其他工具将这些数据源汇总在一起进行事务的端到端的跟踪分析。

综合解决方案

        因此，我们决定分阶段处理此问题，将所有付款活动划分为四大类 - 支付，退款，付款和退货。每个类别都有一个专用的配置管道，用于为该类别中的所有内部和外部支付实体生成所有交易的交易级报告。这使您能够了解类别内和类别之间的趋势。通过计算这些组合类别的移动平均值，我们能够在 Airbnb 的支付生态系统中生成代表交易完整性的单个数字。这个数字使我们能够衡量改进，发现问题并设定总体目标。

        通过这种方法，我们一开始就能够定期跟踪（Airbnb的支付网关开始接收大量流量的那一天）每个阶段的每笔交易。一旦创建了某一个类别所有交易的标准化视图，就可以根据发现的偏离类型进一步对具有异常的交易进行分组。然后，异常归因可以直接与业务用例相关联，例如延迟支付或不匹配的交易属性。而且由于具有类似异常的事务通常需要对数据和/或代码修复进行类似的修复，因此这些错误分组有助于我们优先处理修复工作。

使用传统工具进行付款对账并不充分

        交易完整性举措在许多方面与付款对帐流程不同。事务完整性度量需要比较系统开始运行的日期开始的每个事务，而对帐通常会遗漏已经匹配的事务。完整性测量技术还可以扩展到任何数量的持有交易记录的系统 - 这可以包括多个内部/外部系统。

        通常，仅通过匹配平台和处理器事务来完成支付协调。这排除了交易完整性可能崩溃的关键链接，因为它不提供流程每个阶段的比较结果，而只提供整体情况。通过匹配一组标识属性而不是执行两个模型之间的深度比较来完成支付协调。我们分析的许多第三方协调技术都侧重于会计方面并提供了流程管理工具包，但这些功能并未直接影响事务完整性。

        此外，付款对帐仅在资金交换时完成。但是，有一些交易类型 - 例如取消授权 - 货币从未移动，但仍可能对我们的客户和/或系统性能产生影响。为了维护健康的支付系统，比较所有类型的交易而不是子集是很重要的。

数据湖工具链 - S3， Hadoop/HDFS 和 AirFlow

        Hive 能够直接比较不同模式表示的不同事务模型，只需最少的解释，无需任何额外的集成。这使我们能够快速迭代解决方案。

        Hive 提供了一个类似 SQL 的界面来查询数据，但其最大的优势在于可以有效地大规模执行 MapReduce 作业。有了这个，就可以在整个生态系统中比较各种感兴趣的交易属性 - 金额，货币，支付工具，交易代码，状态等。

        Hadoop 还提供可扩展性，其 MapReduce 机制非常适合在大型和不断增长的数据集之间进行比较。HDFS 使我们能够定期快照事务完整性，以产生有意义的趋势。Amazon S3 为归档目的提供了经济高效的数据存储，并可与我们的数据分析工具包有效地协同工作。

        Airflow 是 Airbnb 开发的工作流组件，它提供了一个用于协调数据操作的调度工具，允许我们执行各种中间计算步骤并生成事务级别报告。

监控和报表工具：Druid, Superset 和自动化报表

        仪表板和自动化报告工具对于提高组织对系统问题的认识以及提供随时间测量性能的工具至关重要。如果没有明确的报告，及时识别客户和业务影响事件往往是困难和耗时的。

        在 Airbnb，我们能够利用基于 Druid（一种低延迟，分布式数据存储）构建的 OLAP系统来摄取我们的事务管道，并以可扩展的方式交互式地探索大数据。利用Superset作为仪表板工具，我们能够不断显示整个支付系统的最新健康指标。通过我们的报告工具中内置的强大支付分类，我们能够随时查看各种系统问题的进展情况，在某些情况下，这些趋势可帮助我们以可扩展的方式处理历史问题。

        异常检测是我们的事务完整性项目的另一个重要结果。我们的 OLAP 系统允许我们轻松配置各种维度的异常检测算法，在我们的数据管道着陆后不久即可实现任何异常的自动Email/Slack通知。

交易完整性分析的关键成果

        事务完整性分析帮助我们识别和区分大小问题，从简单的集成错误到最终一致性的细微差别。它还帮助我们微调各种系统参数，如套接字超时，错误处理和重试机制。

        借助事务完整性数据和辅助工具，在影响我们的用户之前，更容易主动同步“不一致”的事务。这不仅大大削减了大批量，低复杂性的客户支持案例，而且还大大改善了支付协调，从而实现更准确的财务报告和简化的运营。

        深度数据分析还帮助我们轻松监控和理解处理器问题和不当行为。在我们的分析框架之上构建强大的警报功能使我们的系统能够主动通知我们在线事务处理中的处理器中断或丢失/不在SLA事务报告中。

未来展望

        虽然我们在监控和改进迄今为止的交易完整性数据方面取得了很大进展，但未来仍有许多工作要完成，以实现无瑕疵的交易完整性。

        今天在 Airbnb，我们的系统旨在通过自动重试失败的交易来实现“最终的一致性”。重试解决了由于超时，瞬态系统问题，网络连接丢失，中断等原因，我们的系统在允许的时间范围内没有收到下游处理实体的回复情况。这使我们的系统能够与我们的相关处理合作伙伴恢复“同步”状态。

但是，安全地重试付款请求需要强大的幂等保证来执行一个且仅一个货币移动，这对于每个可能的用例都很难实现。通过事务完整性分析，我们获得了如何处理破坏我们的幂等性保证的各种边缘情况的洞察力，并且我们正在重新设计我们的框架以实现近乎完美的幂等性。

近期原创：