每一笔交易，都要做各参与者的记录需要相符，没偏差。对账系统的工作，是找到有差异的记录，即轧帐；然后通过人工或者自动的方式，解决问题这些差异，即追帐。

对电商系统来说，每一笔交易，在所有涉及主体外侧都要能对得上：交易主体，如果发起人是个人，必需需要从个人交易历史记录中寻找这笔交易。但大部分人会保有电子记录，所以一般是获取可以iTunes的账单或交易记录，让用户自己对去。交易输掉，一般是商户。

商户外侧对账处置同用户外侧，也意味着获取对账单。交易渠道外侧，这是对账的重点，一是核实交易流水，二是核实交易佣金，却是是租给人家地下通道做到承销的。

那有哪些记录必须对账？ 目前主要是两个：一个是交易记录；一个是付款记录。对账处置流程一般来说，对账流程牵涉到到如下步骤： 渠道对账单iTunes、本地交易记录打算、轧账、平账。渠道对账单iTunes银行、第三方支付、银联等，基本都会获取对账单iTunes的功能。

不过也有少数工作做到不做到或者过于做到的银行，只获取账单查找后台，不获取对账单iTunes功能。对开发人员来说，这里有几个坑：对账单格式不一，文本、XML、csv的都有。为了先前需要统一处置，在账单iTunes已完成后，必须展开标准化处置。

下载方式不一，HTTP、HTTPS、FTP的，都有。iTunes程序必须按照渠道的协议来处置。

iTunes时间不一，一般是凌晨1点后，到中午12才能用的也有。如果在预计的时间所取将近数据，必须留意重试加载。稳定性劣。FTP服务器出有问题那是常有的事。

渠道外侧解决方案往往就是重新启动。所以重试机制是适当的。

看一下第三方支付的对账单情况：银行直连的对账情况：技术选型上，HTTP(S)用apache httpclient才可构建链接池和断点续传， FTP也可以用于Apache Commons Net API。但不管是哪一个，都必须设置重试次数和链接超强时间。

重试次数和间隔的设置必须小心，重试过于频密，更容易把服务器打伤.；时间间隔过于大，又不会堵塞先前处置步骤。5～10分钟是一个适合的重试间隔区间。

链接超时所指在服务器经常出现问题时，相连在登录时间内提供将近数据即自动插入。这个很更容易被忽视。我们有一次系统出有问题，是渠道外侧的FTP自爆后重新启动，造成我们的客户端挂住，仍然在等候新的链接。

渠道对账单标准化去找个例子大家想到， 比如微信的对账单，他是csv格式的，还包括如下信息：交易时间：这是在微信外侧的缴纳已完成的时间。这个时间不会沦为一个陷阱。公众账号ID、商户号、子商户号、设备号： 这些信息必须做到检验，保证是自己的单子，不要让微信把老王家的单子也给发过来了；微信订单号、商户订单号： 这两个是对单的核心。

前者是微信外侧产生的订单号，在微信缴纳模块返回值中有。但是万一收不到这个返回值，那在本地记录中有可能就机了。

后者是我们发送给微信的订单号，一般用这个来做到对单依据。两边的数据中都会有这个值。用户标识、交易类型、交易状态、缴付银行、货币种类、总金额、企业红包金额： 这几个就是对单的核心字段，必需保证双方是完全一致的。

商品名称、商户数据包、手续费、费率：这些是附加检验。而某宝的对账单，使用文本格式，用空格分隔。他们家的就非常简单很多，只有商户订单号、交易流水号、交易时间、缴纳时间、缴付方、交易金额、交易类型、交易状态这些字段。

由于每个渠道的账单格式都不尽相同， 在获得账单后，下一步是对账单做到标准化处置，这样轧帐以及先前工作就可以统一处置了。标准化后的账单数据可以放到文件系统或者数据库中。这各不相同交易数据量。

每天百万以上的量，还是用于文件系统，较为适合。数据库操作者比较比较慢，也浪费资源。基于文件系统的标准化牵涉到如下内容：文件格式标准化：统一用于csv或者json或者xml格式。

如果是用于hadoop或者spark来对账，用于csv是个不俗的自由选择。文件存储统一化：文件目录，文件名都必须遵循统一命名规范。

为了减缓处理速度，我们用于hdfs作为文件系统，不利于先前的对账的处置。本地交易记录打算本地交易记录的打算，总的来说有如下方法：啥都不做到，必要用原始数据。鉴于大部分系统用于的是mysql，这也意味著在MySQL上做到对账。对账时必须大量的数据查询工作，必定不会影响线上业务。

在数据规模较小，比如多达100万时，就不过于适合了。当然，还有一个自由选择是用于备库来继续执行对账，这样既非常简单，也不影响线上业务。

这是典型的空间换时间的作法。如果业务大到必须分表分库才能处置，那对账数据打算也不一样。用于分库也不现实，因为分库一般是按照主体id，而不是渠道id，来分库，这样对账就必须在多个库上展开，效率反而减少了。

而对分表分库创建从库也十分花费资源。这种情况下，必须实时一份数据到(hdfs)文件系统中，或者NOSQL数据库上。由于交易记录是缴纳系统核心数据，有大量的应用于，如信用、风控等，都必须交易记录数据。

这些应用于对交易记录的市场需求还不完全一致，为了提高性能， 交易记录不会用于异步的方式来将数据投递给用于方。交易记录在入库时，投递消息到消息系统中。

用于方监听这个消息，一旦接到新的消息，则从交易记录库中查找数据，获取数据并改版到库中。关于此类数据实时的文章不少，这里就不详尽讲解。轧帐轧帐是按照客户订单号来较为本地交易记录和渠道交易记录否完全一致。从算法角度，是计算出来两个数组的差异。

在单机运营时，可以使用的算法不少，这里不详尽讲解。我们引荐使用mapreduce来轧帐，这有个优势，可以按照订单号将渠道获取的记录和本地记录shuffle到同一个reduce处置上，这样就可以很更容易展开数据核对。轧帐中仅次于的坑，要数重复点的问题。

比如以整0点为重复点，那不存在一个问题，本地23:59发动的交易，到了渠道外侧，可能会在00:01处置，这一笔交易变为第二天的帐了。实际处置中，一笔交易在渠道外侧处置，花上上几分钟都有可能。对于重复点附近无法证实的帐，做到一个时间窗，在时间窗内的数据，再行第二天对账时之后处置。平帐找到两边不完全一致的数据，那应当如何处置？数据量并不大时，记录一起，人工筛选就讫。

但如果数据量相当大，每天上千条，人工处置就成本太高了。这个没统一的处置方法，必须根据有问题的数据，做到个分析，然后做到自动处置。

针对交易记录的对账的处置，主要有如下情况：本地并未缴纳，缴纳渠道已缴纳。这主要是本地并未准确接管到渠道印发的异步通报造成。

一般处置是将本地状态改动为已缴纳，并做到号召的先前处置，比如通报业务方等。本地已缴纳，缴纳渠道已缴纳，但是金额有所不同，这个必须人工核查。本地已缴纳，但是缴纳渠道中无记录；或者本地无记录，缴纳渠道有记录。在回避横跨日因素外，这种情况十分少见，必须理解明确原因后做到处置。

针对付款的对账处置，主要有如下情况：本地并未付款，缴纳渠道已付款，则以缴纳渠道不尽相同，改动本地为已付款状态，并抵达先前处置。本地已付款、缴纳渠道已付款，但是金额有所不同，必须人工核查；本地已付款，但是缴纳渠道无记录；或者缴纳渠道有记录，但是本地没。在回避横跨日因素外， 这种情况十分少见，必须理解明确原因后做到处置。

总之，对账工作，即简单也不简单。必须细心，对业务要有了解的理解，并自由选择适合的架构。涉及读者：缴纳系统设计：缴纳系统的账户模型（一）(公众号：)录：本文由人人都是产品经理社区作者@凤凰牌老熊（微信公众号：shamphone）原创公布。

凤凰牌老熊，程序员架构师。先后在中科辅龙、三星（中国）研究院和国内一些大型的互联网公司工作过。

2014年重新加入爱人奇艺，负责管理数据仓库和缴纳系统的建设。文章未经许可，不得刊登。

原创文章，予以许可禁令刊登。下文闻刊登须知。

本文来源：c7娱乐游戏-www.tuorange.com