我们聊聊对帐系统该如何设计

在互联网行业中只要涉及到支付，必然就会有对帐的需求，几乎全部互联网公司的业务中多多少少的都会涉及到支付，大一点的公司甚至都标配有了本身的第三方支付公司，所以对帐具备广泛性。对帐系统是支付体系中最重要的一环，也是保证交易、资金安全的最后一道防线。在大多数的互联网公司中，通常都会有独立的对帐系统来处理，好比：电商平台、互联网金融、第三方支付公司等。

对帐是支付系统中的一环，所以在对帐前咱们先了解一下相关的业务知识

业务知识

什么是对帐

传统的对帐就是核对帐目，是指在会计核算中，为保证帐簿记录正确可靠，对帐簿中的有关数据进行检查和核对的工做。在银行或者第三方支付中，对帐实际上是对必定周期内的交易进行双方确认的过程，通常都是在次日银行或者第三方支付公司对前一日交易进行清分，生成对帐单供平台商户下载，并将应结算款结算给平台商户。在往下一层，在互联网金融行业或者电商行业中，对帐其实就是确认在固定周期内和支付提供方（银行和第反方支付）的交易、资金的正确性，保证双方的交易、资金一致正确。

广义的对帐，全部跨应用的数据交互，理论上都应该进行对帐。因此对帐也能够分为信息流对帐，资金流对帐。信息流对帐也通常用在本身内部系统的对帐，好比支付系统的支付数据和业务系统的业务数据进行对帐，保证资金交易和业务交易的一致性。资金流对帐也就是支付系统和银行或者第三方支付系统之间的资金交易对帐。

对帐方式

• 单向对帐：通常拿第三方支付机构或银行流水，与本身系统进行对帐，防止出现掉单问题；
• 双向对帐：两个应用间的流水进行双向核对，如订单与财务系统，既要保证财务系统支付成功的记录，订单系统也是成功的；也要确保订单系统记录成功的记录，财务系统也成功。

咱们通常采用双向对帐的方式进行对帐

对帐相关的问题

不一样系统日切点不一致问题：滚动对帐
差错处理：补帐，补偿（退款）

相关概念

轧账和平账

每一笔交易，都要作到各参与者的记录可以吻合，没有误差。对帐系统的工做，是发现有差别的记录，即轧账；而后经过人工或者自动的方式，解决这些差别，即平账。

长款和漏单

在以平台交易为基准的状况下和银行对帐，发现周期内的交易，平台有此订单而第三方支付中没有订单，成为平台长款。平台长款通常是因为用户在支付的时候跨天的状况，好比用户在23:58分建立了订单，在次日的凌晨00:03分进行了支付。在以银行交易为基准的状况下对帐，银行有此订单而平台无此订单，即为平台漏单。平台漏单不多见，通常直接转人工处理。

帐户体系

在通常的支付体系中会分为登陆帐户和支付帐户，支付帐户指用户在支付系统中用于交易的资金全部者权益的凭证；登陆帐号指用户在系统中登陆的凭证和我的信息。一个用户能够有多个登陆帐户，一个登陆帐户能够有多个支付帐户，好比零钱帐户、储值卡帐户等。通常来讲，支付帐户不会在多个登陆帐户之间共用。对帐的交易通常都是支付帐户参与交易。

交易与帐户

帐户设置，通常是从交易开始的。 交易的实现必须有帐户的支持，帐户是交易的基本构成元素。 从支付系统的角度，交易中涉及到的资金流是资金从一个帐户流向另外一个帐户。 发起交易的一方，被称之为交易主体，他能够是一我的，也能够是一个机构。

清算和结算

清算主要是指不一样银行间的货币收付，能够认为是结算进行以前，发起行和接收行对支付指令的发送、接收、核对确认，其结果是全面交换结算工具和支付信息，并创建最终结算头寸。

结算是指将清算过程产生的待结算头寸分别在发起行、接收行进行相应的会计处理，完成资金转移，并通知收付双方的过程。当前，大多数银行结算业务的完成主要经过两类帐户：一是银行间互相开立的代理帐户，二是开立在央行、独立金融机构如银联、或者第三方支付机构的帐户。

清算：计算各方应收应付钱款的时间与金额。结算：根据清算的结果在指定的时间对各方进行实际的资金转移操做

资金池

用户备付资金（如充值）统一放在企业的银行帐户中，企业能够随意支配这些资金，即为资金池。与之对应的是第三方托管，用户备付资金是放在企业在第三方支付机构为用户开设的虚拟帐户中，企业没法随意取出这些资金。如今互联网金融全面要求接入银行存管，就是银行会为每一个用户建立一个资金帐户来保护用户的资金，互联金融公司不能随意划拨这些资金帐户中的金额。

对帐系统

对帐设计

对帐系统的设计阶段，将对帐系统分为四个模块，每一个模块的负责本身的职能。

• 文件获取模块：下载或者读取各渠道对帐文件
• 文件解析模块：建立不一样的解析模板，根据渠道和文件类型获取对应的解析模板进行解析
• 对帐处理模块：对帐的业务逻辑处理
• 差错处理模块：处理差错池中的订单

通常会设计一个定时任务，天天固定的时间点触发，定时驱动调度类分别调用四个模块来处理对帐。也有的银行会主动的推送对帐单，再经过http回调来触发对帐流程。

对帐算法

1、流程：

一、从上游渠道（银行、银联等金融机构）获取对帐文件，程序逐行解析入库；
二、在程序处理中，以上游对帐文件的表为基准，程序逐行读取并与咱们系统的交易记录对比帐务记录（有帐务系统状况下，合理方案应该是于帐务记录）对比，查找出差别记录；
三、以咱们系统的交易记录对比帐务记录为基准，程序逐行读取与上游对帐文件对比，查找出差别记录。

2、缺陷：

一、对帐过程当中查询相关数据，若是数据量巨大，对数据库性能影响较大，并且对帐逻辑扩展极为麻烦；
二、逐行比对算法效率较低，但算法上并没有好的优化余地。若是采用数据库INTERSECT、MINUS对数据库压力也高；
三、在业务量大的状况下（例若有上百家上游渠道须要对，每一家都有几十万条交易记录），对帐服务器及数据库服务器负荷较高。即使采用读写分离，对帐时候使用读库，压力同样很大；
四、导入批量文件，逐行入库效率较为低下（每一次都须要创建网络链接、关闭链接）。

3、改进：

一、涉及网络传输的，尽可能采用批量方式操做，减小网络消耗及时间消耗；
二、使用Redis等NOSQL数据库，下降数据库服务器的压力。同时在扩展上也容易，一台Redis服务器不够，能够无限制增长用于对帐用的服务器；
三、使用Redis的set集合的sdiff功能，利用Redis sdiff算法的高性能，比对上游记录和我方记录的差别。

对帐流程

一、下载对帐单

大多数银行都要求接入方提供ftp服务，银行定时将对帐单推送到接入方提供的ftp服务器上面；还有一部分银行会提供对帐单的下载服务，经过ftp/http的都有，ftp方式居多；另外网银的对帐单比较特殊，通常都须要结算登陆网银的后台管理系统中，手动下载，结算下载完对帐单后在导入到对帐系统。

技术实现上能够作成工厂模式，不一样的支付渠道有不一样的下载类，若是是http接口将文件写入到对帐单，若是是ftp服务器，将服务器中的对帐单下载到本地带解析的目录中。主要涉及的代码ftp工具类、http(s)工具类，相关IO读写。

技术选型上，HTTP(S)用apache httpclient便可实现连接池和断点续传， FTP也可使用Apache Commons Net API。 但无论是哪个，都须要设置重试次数和连接超时间。重试次数和间隔的设置须要当心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。

二、建立批次

建立批次一方面是为了防止重复对帐，另外一方面须要在对帐结束的时候将对帐的结果信息存储到批次中。

三、解析文件

解析文件主要是将下载的对帐文件解析成咱们能够对帐的数据类型而且入库。解析的文件不一样渠道有不一样的类型，所以也能够设计成不一样的解析模板，使用工厂模式将不一样格式的文件解析成能够对帐的统一数据类型。解析的文件类型通常包括：json、text、cvs、excle等，另外部分银行会对帐单作加密或者提供zip打包的格式，这里就须要额外开发zip工具类和加解密工具类进行处理。

对帐文件中包含的主要信息有：商户订单号、交易流水号、交易时间、支付时间、付款方、交易金额、交易类型、交易状态这些字段。

四、对帐处理

对帐处理也是对帐的核心逻辑，具体分为如下的几个步骤来实现：

• 查询平台全部交易成功的订单
• 查询平台全部的交易订单
• 查询平台缓存池中的数据
• 查询银行交易成功的订单
• 开始以平台的数据为准对帐,平台长款记入缓冲池
• 开始以银行通道的数据为准对帐

以平台订单为基准对帐逻辑：以平台全部交易成功的订单为基准，遍历银行订单的全部数据，找出订单号相同的订单，对比订单的金额、手续费是否一致。若是一致跳过；若是不一致，平台订单进入差错池；若是在银行订单中没有找到此笔交易，订单进入缓存池，记录平台长款。同时统计对帐相关金额和订单数。

以银行订单为基准对帐逻辑：以银行的交易数据为基准，遍历全部平台的交易（包括未成功的订单），找出订单号相同但支付状态不一致的订单，在进行对比金额存入差错池。若是没有在平台的交易中找到此订单，再从缓存池中遍历查找，找到对应的平台订单验证金额是否一致，不一致进入差错池。若是在缓存池汇中依然没有找到对应的订单，直接进入差错池，记录平台漏单。同时统计对帐相关金额和订单数。

五、对帐统计

根据对帐处理中，统计的相关信息包括：对帐完成时间、对帐是否成功、平帐的金额和订单数、差错的金额和订单数、缓存池金额和订单数等。

六、差错处理

在通常系统中，差错处理分为两种，一种人工来处理，一种系统自动来处理。

主要有以下状况：

• 本地未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知致使。 通常处理是将本地状态修改成已支付，并作响应的后续处理，好比通知业务方等。
• 本地已支付，支付渠道已支付，可是金额不一样，这个须要人工核查。
• 本地已支付，可是支付渠道中无记录；或者本地无记录，支付渠道有记录。在排除跨日因素外，这种状况很是少见，须要了解具体缘由后作处理。