更多支付内容请移步个人站：YKBLog.top
对账整体设计
从整体来看，按照时序维度的先后，系统对账主要分为三阶段的工作。分别是数据准备、数据核对和差错处理。
- 数据准备细分一下，又分为文件获取、文件解析、数据清洗。
在对账专业概念中，数据核对和差错处理又叫轧账和平账。
具体设计脑图如下:
check-arch.png
对账各个模块设计
数据准备
数据准备，顾名思义，我们需要把对账所需的全部数据，接入到我们的对账系统。
该模块主要实现两个目标：
- 为不同的外部系统提供多元化的接入机制。
- 通过数据适配的手段把外部数据以统一的格式进行转换和存储。
在数据接入层，我们会针对不同的数据接入方提供三种不同的数据接入模式。如下图：
check-data-deal.png
数据拉取
主动拉取数据，并通过数据适配的方式，将数据存储到对账数据池中。
数据推送
指定标准规范和格式，供各个接入方使用，统一格式推送到对账服务。
人工上传
提供标准的文件模板，由业务接入方填充数据，通过后台文件上传或SFTP上传工具的方式将数据上传到对账服务。
check-data-file.png
人工上传文件处理方式步骤如下：
- 下载文件
从指定SFTP服务器下载文件。 - 解压文件
一般为zip压缩包，节省存储空间，提高上传和下载速度。 - 解析文件
一般文件格式为EXCEL（财务人工上传文件，一般从银行或第三方支付后台下载）、CSV（数据接入方一般从数据库导出格式，或第三方支付提供的文件格式）、TXT。 - 存储数据
将第三步得到的数据存储、持久化到数据库，一般底稿数据都存储最全数方便问题追溯。
数据清洗
顾名思义，即对准备的上下游数据进行清洗。
清洗的作用或原因：
从底稿提取对账核心字段
一般参与对账的字段就几个，具体字段：银行卡号、银行单号、业务单号、支付金额、支付方式、支付完成时间、核对状态。
上文提到底稿一般建议存储所有数据，数据太多影响对账性能和效率。
合并、排除无用数据
上文提到底稿一般建议存储所有数据，难免有无用数据需要剔除，或者排除业务或财务指定无需对账的数据；合并特殊业务或流程产生的N对1数据。
数据核对
对账的核心
数据核对是对账的核心，对账的主逻辑；一般对账方式有两种，即对明细账和对总账，对总账一般包括总金额和总条目。一般做法为对明细账，即上下游每条记录逐一比对。
核对的结果
核对一般就是两个结果：对上帐和对不上账，对不上账有分三种结果，上游单边（支付中一般称为企业单边，即长款），下游单边（支付中一般称为银行边，即漏单），金额不等（即两边都有数据，金额对不上）。
设计normal和different两张表，分别存储不同的核对结果数据，方便后期统计以及为业务提供能力。
check-data-check.png
具体对账的方法有多种，比如：
- sql核对
exist insert select
最简单的方式，也是问题比较多方式，对数据库压力比较大，数据特别多的时候，对账效率比较低。 - redis核对
set集合分别diff （inter）上游、下游数据
比较好的方式，可以降低数据库压力，redis方便根据数据量做水平扩展。 - sprak核对
采用流式运算进行比对；（具体做法待扩展）
差错处理
在一般系统中，差错处理分为两种，一种人工来处理，一种系统自动来处理。
人工处理一般两个操作：平账和勾兑，勾兑一般处理的是单边情况，比如由于系统bug出现的单边问题，经由人工溯源修复bug之后，相关业务人员即可在对账后台将该条数据进行勾兑。
系统自动处理一般为：自动补单和驱动下游流程完成两种方式。主要有如下情况：
下游单边（银行单边）情况
业务未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。
一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
上游单边（企业单边）情况
业务已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。
在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。
金额不等情况
业务已支付，支付渠道已支付，但是金额不同，这个需要人工核查。
对账统计
根据对账处理结果，统计的数据由：汇总总条目、汇总总金额、汇总差异结果、汇总单边结果、汇总处理结果。
业务和财务关系的统计的相关信息有：对账完成时间、对账是否成功、平账的金额和订单数、差错的金额和订单数、缓存池金额和订单数等。
check-result.png
对账系统相关设计
分布式定时系统
一般对账系统都是N+1离线对账，所有上述所有模块的设计一般使用定时任务去执行。不可能所有模块、所有银行卡都用一个任务去执行，也不可能只用一台机器去执行，这样一天可能都跑不完所有的数据。
所以考虑到优化，一般设置为集群分布式的去跑任务，所以涉及一个分布式定时系统对对账系统来说很重要，考虑成本和时间问题，可以简单实现分布式任务效果。分布式定时系统的设计后续再单独探讨。
即使所有任务都按模块化去进行划分，按模块化单独起任务去执行业务逻辑，也会存在时间效率的瓶颈（因为下文提到的依赖关系，导致并不能让所有的任务都并行起来）。再加上银行卡号比较多的情况下，最好情况就是各个银行卡号并行处理，即并发粒度设计到银行卡号维度，使用多线程把所有银行卡的对账任务并行起来。
依赖链设计
所有模块是存在依赖关系的，比如清洗之前，肯定要数据准备完成；但是上游数据和下游数据的准备、清洗可以并发的执行。整体依赖链如下：
check-depend.png
核心对账优化
上文模块设计有提到核心对账的多种实现思路，这里推荐的两种：
- redis 实现
- sprak 实现
具体实现过程会在后续博文中详细介绍。
对账系统数据库模型
按以上设计模型，具体数据模型如下介绍。
底稿数据表
- 各个上游数据、下游数据抓取、解析的底稿数据 。
- 不只两张表，由具体业务决定；数据量比较大，一般按日期水平分表，按实际业务考虑要不要垂直分表。
清洗表
- 从各个上游数据、下游数据的底稿数据取部分字段。
- 不只两张表，由具体业务决定；数据量比较大，一般按日期分表。
对账结果表
- 正常表
用来存放对上账的数据(即对账结果正常的数据，一般数据量比较大，需要按日期分表) - 异常表
用来存放对不上账的数据（上游单边、下游单边、金额不等）。
对账汇总表
即对对账数据的汇总
技术相关表
定时配置、账户配置、异常信息等等相关表
更多支付内容请移步个人站：YKBLog.top
网友评论