引言
对账，官方释义为核对账目；主要指在会计核算中，为保证账簿记录正确可靠，对账簿中的有关数据进行检查和核对的工作。而在互联网领域，多取其狭义上的定义，指第三方支付机构对一定周期内的交易进行双方确认的过程。细思深究，也颇有一番道理；以清结算为安身立命的第三方支付机构，对账自然是其重中之重的业务模块之一。
说到第三方支付，莞尔一笑；斯认为其称得上互联网领域的青楼，迎来送往，寒暑不息。青葱拨弄，弹一曲花好月圆，博得互联网金融，电商平台类的达官贵人一笑；翻云覆雨，苦短良宵，也侍弄的O2O慷慨解囊。偶有被官人翻了牌子，私定终身的，也算寻得一个好人家，免却了杜十娘怒沉百宝箱。
闲言不语，书归正传；翻阅良久，寻得互联网金融，电商等2C类平台对账系统设计的文章甚少，固撰此文，权当填补空缺之作；也算温故知新，回顾总结。
正文
对账，分开看：对，成双之意，双人成对；账，钱财往来记为账。通俗来讲，对于互联网平台，但凡涉及支付业务的，平台及合作的第三方支付机构均做记账；而对账，即为就双方所记账目进行核对。核对过程，最简单的方式，双方单日交易明细，拉两个Excel，然后用交易流水号做VLOOKUP，此为手动对账。对账系统，顾名思义，以系统的方式自动的周期性进行此工作，此即为本文所描述的—非第三方支付的互联网领域平台对账系统设计。
支付业务流程
正式讲述对账系统设计之前，有必要简单阐述一下支付的业务流程，先上图：
总体来看，一般互联网平台对于支付业务的结构及流程均类似，一一道来：
业务：业务很好理解，互联网金融，电商，O2O即为业务；
账户中心：有人的地方就有江湖，有平台的地方就有账户，账户中心作为用户在平台的载体，对于支付业务中的账务处理是必不可少；
网关路由：通常对于业务是不直接同第三方支付进行交互的，网关一方面负责统一对接第三方支付，另一方面也会做一些路由，供业务更灵活的调用第三方支付；
三方支付：三方支付不多做说明，仅提一点，平台做到一定量的时候，肯定不会只是单支付渠道进行支撑的；
代扣：支付种类的一种，简单理解，类似房贷，签订协议后由第三方支付周期性代为在用户指定的银行账户进行扣款；
代付：同样为支付种类的一种，类似工资发放，由第三方支付代为向用户指定的银行账户发放资金；
快捷支付：常见的支付种类，由用户主动发起支付操作，通过银行卡号，实名认证信息及银行预留手机号码的短信验证码进行验证支付；
银行：由第三方支付对接；
以上，便为支付业务流程中所涉及到的基本方面及各自所负责的职责，而对账，即为核对平台和三方支付间的账。
对账流程
再上一图：
一一道来：
本地交易记录准备
本地交易记录的准备，总的来说有如下方法: – 啥都不做，直接用原始数据。鉴于大部分系统使用的是mysql，这也意味着在MySQL上做对账。对账时需要大量的数据查找工作，必然会影响线上业务。在数据规模较大，比如超过100万时，就不太合适了。
- 当然，还有一个选择是使用备库来执行对账，这样既简单，也不影响线上业务。这是典型的空间换时间的做法。
- 如果业务大到需要分表分库才能处理，那对账数据准备也不一样。使用分库也不现实，因为分库一般是按照主体id，而不是渠道id，来分库，这样对账就需要在多个库上进行，效率反而降低了。而对分表分库建立从库也非常耗费资源。这种情况下，需要同步一份数据到(hdfs)文件系统中，或者NOSQL数据库上。
由于交易记录是支付系统核心数据，有大量的应用，如信用、风控等，都需要交易记录数据。这些应用对交易记录的需求还不完全一致，为了提升性能， 交易记录会使用异步的方式来将数据投递给使用方。交易记录在入库时，投递消息到消息系统中。使用方监听这个消息，一旦收到新消息，则从交易记录库中查询数据，获取数据并更新到库中。关于此类数据同步的文章不少，这里就不详细介绍。
本地网关交易记录数据字段如下：
对账文件获取
对于第三方支付机构通常会以日为单位提供其商户不同格式的文本形式的交易明细文件，即为对账文件。所有的第三方支付机构均提供对账文件的下载功能。
对开发人员来说，这里有几个坑：
- 对账单格式不一。文本，XML，csv的都有。为了后续能够统一处理，在账单下载完成后，需要进行标准化处理。
- 下载方式不一，HTTP，HTTPS，FTP的，都有。下载程序需要按照渠道的协议来处理。
- 下载时间不一，一般是凌晨1点后，到中午12才能用的也有。如果在预定的时间取不到数据，需要注意重试读取。
- 稳定性差。FTP服务器出问题那是常有的事。渠道侧解决方案往往就是重启。所以重试机制是必要的。
技术选型上，HTTP(S)用apache httpclient即可实现链接池和断点续传， FTP也可以使用Apache Commons Net API。 但不管是哪一个，都需要设置重试次数和链接超时间。重试次数和间隔的设置需要小心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。
总结如下：
由于各三方支付对账文件的传输方式，传输时间，传输格式都不尽相同，固关于文件的获取机制说明如下：
1、分时定时，根据各三方支付对账文件可获取时间，分时段定时分别进行对账文件的获取
2、重试机制，考虑到ftp等服务器稳定性较差的因素，对账文件的获取需要有5-10分钟的重试机制
3、断点续传，对于传输文件过程中断的情况，需在重试机制再次执行任务时支持其断点续传
4、链接超时，在服务器端出现问题时，链接在指定时间内获取不到数据即自动断开，防止一直进行重新链接
5、文件判断，需有文件判断机制，判断对账文件是否完整可用
创建批次
创建批次一方面是为了防止重复对账，另一方面需要在对账结束的时候将对账的结果信息存储到批次中。
对账批次格式： 支付渠道_商户号_业务类型_对账日期_序列号
如：lianlian_129503432_kuaijie_20170915_1
对账文件格式规范
由于每个渠道的账单格式都不尽相同， 在得到账单后，下一步是对账单做标准化处理，这样后续工作就可以统一处理了。 标准化后的账单数据可以放在文件系统或者数据库中。这取决于交易数据量。每天百万以上的量，还是使用文件系统，比较合适。数据库操作相对比较慢，也浪费资源。
基于文件系统的标准化涉及如下内容：
文件格式标准化：统一使用csv或者json或者xml格式。如果是使用hadoop或者spark来对账，使用csv是个不错的选择。
文件存储统一化：文件目录，文件名都需要遵循统一命名规范。
为了加快处理速度，我们使用hdfs作为文件系统，有利于后续的对账的处理。
对账文件命名格式规范：
文件名称：业务类型_三方名称_对账日期_序列号_文件格式
名称示例：O_lianlian_20170915_02.csv
1、业务类型，入款I（input），出款O（output），退款R（refund）
2、三方名称，baofu（宝付），jinyuntong（金运通），lianlian（连连）
3、对账日期，YYYYMMDD
4、序列号，同一支付三方同一业务可能有多个对账文件
5、文件格式，取决于最终对账处理方式
对账文件内容格式规范：
对账核心
对账单数据整理规范后，进行对账时，需将对账单中订单、金额与平台系统订单、金额进行比对。
对账核心相关概念说明：
对账核心，输出结果：
对账结果统计
T日对账任务全部完成后，更新T日对账结果，参考如下：
以上为按对账批次汇总数据
当前批次对账任务完成后，同步更新当前批次对账结果，参考如下：
以上为各对账批次内具体对账结果，按订单编号展示。
差错处理
差错处理需达到2个效果，一个是完成对账，另外一个是将账务对平，常见的账务处理方式有挂账、登账、调账。
补单：通过人为干预方式，将原有业务进行下去，如通过接口人工干预订单状态
挂账：对于不平账单，先挂起，等查明后再进行相应处理
登账：会计记账，伴随虚拟资金从一个账户向另一个账户转移的过程（原始凭证）
以上，简单来说，即为通过不同的方式对差错池中的数据进行不同的处理，差错池数据格式，可参考如下：
不同差错处理类别如下：
以上，即为非第三方支付的互联网领域平台对账系统设计，最后附上整体对账系统架构，供参考：
