收单-基于文件方式的批量交易处理思路

最近做了个涉及批量交易的需求，发现蛮多要点的

1. 需求背景

1.1 业务概述：

商户是水电煤类企业，主要通过该功能，实现批量扣费。单笔批量支付交易量5千-2万。

1.2 需求流程分析：

1. 商户先上传批量支付文件，然后触发批量支付接口；
2. 收单系统接收批量支付请求后，根据文件ID，下载和解析商户上传的批量支付文件，将文件内的批量订单明细，入到订单表中；
3. 根据渠道方要求，按规则对订单做拆分，拆分成相关子批次，然后发送给渠道方；
4. 主动查询子批次的处理结果，处理完成，会返处理结果文件路径。FTP服务器上。需要主动去查询处理结果；
5. 前往FTP服务器上下载文件，解析文件，根据处理结果更新订单明细状态，以及子批次信息；
6. 扫描主批次下的所有子批次，是否以及都处理完成了？都完成了就可以生成主批次的处理结果文件，以便返回给商户。

整个批次交易，需要控制在2个小时左右完成。

注意：在考虑文件的下载与解析入库的场景时，要考虑应用是单体架构还是分布式的。如果是分布式，并且没有NAS共享盘的情况下，要考虑好文件临时存放的问题，文件的下载和解析操作要保证在同一台服务器上处理。那么在流程设计上，拆分时注意这点。

1.3 流程设计

方案一：基于定时任务扫描处理；
方案二：基于MQ消息驱动处理。

这里实际应用了基于定时任务的方案，基于MQ消息的方案其实是后面优化的设想。两者区别不是很大。MQ驱动在整体时间控制上会更有优势。以下是定时任务的设计：

• 任务一：批量支付文件的下载和解析入库，这里下载和解析入库操作是放在一起的；
• 任务二：根据规则拆分子批次；
• 任务三：根据子批次查询对应订单明细，生成批量支付文件，上传FTP服务器；
• 任务四：调用渠道批量支付接口，上送批量支付交易和文件路径；
• 任务五：调用渠道批量支付查询接口，主动查询处理结果；
• 任务六：下载并解析交易结果文件，并更新订单信息和子批次信息；
• 任务七：扫描主批次对应的子批次是否完成交易。都完成了根据主批次信息生产商户批量支付结果处理文件。

2. 接口和表设计

2.1 对外接口设计

1. 文件上传接口：商户上传文件，内容主要包含每笔交易明细，以及汇总笔数、金额、用途，文件上传成功，返回文件ID信息；
2. 批量支付接口：上传批处理流水，文件ID，交易汇总笔数和金额等信息；
3. 批量支付查询接口：查询批量支付结果信息，如果处理完成，那么返回处理结果文件ID；
4. 文件下载接口：商户下载批量结果文件。

2.2 表设计

1. 批次表：记录商户发起的批量支付交易信息；
2. 子批次表：记录与渠道交互的批量支付交易信息；
3. 订单流水表：记录批量支付里面每笔明细见交易信息。