一、背景简介

大家好，今天分享支付系统中的对账处理模块，对账业务就不细讲了，大家可以去看群主的“支付系统设计：对账处理”那篇文章，里面详细介绍了对账的业务处理。
今天主要讲百万级别以上交易笔数的对账如何在30分钟之内对账完成，以满足快速清算的目的。
我们先来梳理下对账中有哪些环节：

整个环节中就是系统对账模块是最耗时的，因为需要逐笔进行勾兑来找出双方差异的单来进行长短款处理和对平账数据的清算处理。
我先讲下背景环境：公司支付系统对接了微信、支付宝、QQ钱包等主流移动支付通道。每天9天上游才提供对账单，10:20要完成所有通道的商户清算。

二、 对账优化

如何优化这块的对账处理时间，我总结了一下几点，

  1. 渠道对账单数据清洗
  2. 存储IO优化
  3. 数据库查询优化

1、渠道对账单数据清洗

我们先来说对账单数据清洗，数据清洗比较简单，难的是清洗完成之后怎么存储，然后在后续的勾兑中能快速的可以查询出来进行比对。
我们这里选择的kv数据库ssdb来进行数据存储，为什么选择ssdb？因为其高性能的存储和查询速度。
处理程序上根据不同的渠道采用多线程来进行账单下载和数据清洗之后然后存储在ssdb中，这个过程中500W的数据基本在5分钟之内都可以处理完成。

2、 存储IO优化

接着来说存储IO优化，这点是最重要的，因为这里对第一点和第三点的优化起着很重要的作用，我们选择的ssd的固态硬盘来进行清洗数据的存储和数据库数据的存储，以及ssdb数据文件的存储。 特别是ssdb专门是对ssd进过优化的，更加提高了ssdb的性能，这个也是为什么选择ssdb来存储勾兑数据的原因之一。
这里如果公司成本控制有限的话可以选择数据库还是采用机械硬盘来存储，因为对整个优化影响不大，我们这里数据库采用ssd来存储是因为成本上公司能支持，算是锦上添花的效果。但是ssdb一定要安装在ssd上。

3、 数据库查询优化

最后来说数据库查询的优化，先说查询语句的优化，索引很重要，因为支付的特性，主要关心的是根据订单、渠道、时间来进行查询，所以这些字段就一定要建立索引，这里建议大家建立复合索引，尽量减少索引来提高存储的速度。
所以我一般会建立订单索引、渠道+时间的复合索引；其他的sql优化方案根据大家各自的系统进行优化设计。
但是sql优化还是不够，因为还是满足不了在很短的时间之内把数据查询出来并进行勾兑处理，所以有两个解决方案，一个是在时间上去优化，一个是在空间上去优化，我这里选择用空间来换时间。
因为数据库系统需要查询的是T日的交易数据在T+1日来进行对账，所以我选在T日日切之后，将T日的数据全部查询出来写到ssdb数据库中，这样一来我可以在9点下渠道对账单之前就将我方订单数据全部处理完成，在渠道数据清洗成功之后就可以马上进行数据勾兑，500W笔的数据量在20分钟之内就可以全部处理完成。

Q&A

Q: 基于sql的对账？
A: 不是，基于nosql的的对账；订单在关系型数据库，日终把订单数据数据同步到ssdb中用来对账。

Q1: 请问渠道单的下载是分块下载嘛？渠道单下载 之后清洗 再写入ssdb 这个过程可以详细说一下嘛？
A1: 不用分块下载，渠道侧会提供压缩之后的账单
Q2: 那需要再代码中进行解压啦？还是怎么处理，百万的数据也不是一次性加载到内存的吧？
A2: 数据清洗之后，按渠道号做做为key，把订单组装成hashmap作为value存进去，不是一次性的，循环去遍历渠道对应的ssdb。
Q3: 渠道单下载之后是用什么工具解析的 ？
A3: 对账单只是文件IO读写，对账单下载之后进行解压，然后一行行的读取文件内容写入到ssdb中
Q4: 如果对账单很大的话，怎么处理的，文件几百兆或是上G
A4: 1G的文件读取和解析入ssdb也就3分钟处理完了，但是这个解析过程不要做别的业务处理，单纯只做数据清洗。一般不会太大，如果太大的话，比如每天上亿笔交易，这就是另外一种架构处理了，都是用csv或者txt不会有几百兆的。

Q: 没有数据处理的导入其实可以做到很快的，但这样的话岂不是每个渠道都要建立一个导入模型？还是说清洗的时候已经做了数据处理？
A: 数据清洗就是为了把不同渠道的数据转换成统一的数据格式。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。