设计千万级高可用分布式对账系统

一、背景

目前线上业务量与日俱增，每日的订单量超过千万，资金流动大，资金安全成为了重点关注的问题。为了确保每一笔交易的正确性，提高资金的正确性和保障业务的利益，除了RD代码逻辑严格以外，还需要对每日甚至每小时订单的流水进行核对，对异常情况能及时处理。面对千万级的订单量，人工对账肯定是不可行的，所以，实现一套对账系统成为了必然的事，不仅为资金安全提供依据，也节省公司运维人力，数据更加可视化。

目前这套系统已覆盖聚合渠道网关与外部渠道100%的对账业务，完成春晚期间支付宝亿级订单量对账，完成日常AC项目千万级订单量对账，对账准确率实现6个9，为公司节省2~3个人力。

二、介绍

对账模块是支付系统的核心功能之一，不同业务设计的对账模型不同，但是都会遇到以下几个问题：

• 海量的数据，就目前聚合支付的订单量来看，设计的对账系统需要应对千万级的数据量；

• 面对日切、多账、少账等异常差异订单应该如何处理；

• 账单格式、下载账单时间、下载方式等不一致问题。

针对以上问题，并结合财经聚合支付系统的特点，本文将设计一套可以应对千万级数据量、分布式和高可用的对账系统，利用消息队列Kafka的解耦性解决对账系统各模块之间的强依赖性。

文章从三个方面介绍对账系统，第一方面，总体介绍对账系统的设计，依次介绍各个模块的实现及其过程中使用到的设计模式；第二方面，介绍对账系统版本迭代的过程，为什么需要进行版本迭代，以及版本迭代过程中踩过的“坑”；第三方面，总结现有版本的特点并提出下一步的优化思路。

三、系统设计

1.系统结构图

图1为对账系统总结构图，分为六个模块，分别是文件下载模块、文件解析并推送模块、平台数据获取并推送模块、执行对账模块、对账结果统计模块和中间态模块，每个模块负责自己的职能。

图1 对账系统总结构图

图2为对账系统利用Kafka实现的状态转换图。每个模块独立存在，彼此之间通过消息中间件Kafka实现系统状态转换，通过中间态UpdateReconStatus类实现状态更新和message发送。这种设计不仅实现流水线对账，也利用消息中间件的特点，实现重试和模块之间的解耦。

图2 对账系统状态转换图

为了更好的了解每个模块的实现过程，下面将依次对各个模块进行说明。

2.文件下载模块

1）设计

文件下载模块主要完成各个外部渠道账单的下载功能。众所周知，聚合支付是聚众家三方机构能力为一体的支付方式，其中三方机构包括支付宝、微信等支付界的领头羊，多样性的支付渠道导致账单下载存在多样性，如何实现多模式、可拔插的文件下载能力成为该模块设计的重点。分析Java设计模式的特点，本模块采用接口模式，符合面向对象的设计理念，可实现快速接入。具体实现类图如图3所示（只展示部分类图）。

图3 文件下载实现类图

下面就以支付宝对账文件下载方式为例，具体阐述一下实现过程。

2）实现

分析支付宝接口文档，目前采用的下载方式为HTTPS，文件格式为.csv的压缩包。根据这些条件，本系统的实现方式如下（只摘取了部分代码）。由于消息中间件Kafka和中间态模块的机制，已经从系统层面考虑了重试的能力，因此不需要考虑重试机制，后续模块也如此。

public interface BillFetcher {
      // ReconTaskMessage 为kafka消息，    // FetcherConsumer为自定义账单下载后的处理方式    String[] fetch(ReconTaskMessage message,FetcherConsumer consumer) throws IOException;}