1000W交易数据对账，如何做到性价比最（jiao）高？

对账，是一个支付系统的必备功能。
如何做到性价比最（jiao）高？
是一个应该思考的问题。

所谓“性价比”，在我看来，就是技术方案要符合公司的基本情况，正所谓经济基础决定上层建筑。合格的技术方案，既要满足现有业务的要求，又要预留足够的可扩展性，这样就能可持续发展，而不是一遍又一遍的造轮子。

现在，我们要对1000万交易数据做对比，该如何制定方案呢？

因为我们是小厂，杀鸡用不起牛刀，所以不能照搬全套的大数据平台（实际上是没有）。那么我们能选择的就只有两种方式：

• 数据库对比（包括Redis）
• 代码对比

数据库对比

优势

• 简单，可靠

不足

• 千万级别数据对比处理时间长（分钟级别），数据库压力较大
• 可能会影响日终结算等凌晨任务
• 扩展性不足

代码对比

优势

• 灵活
• 对数据库服务器压力非常小
• 可根据数据量级，选择单机或者分布式模式

不足

• 需要占用较大磁盘空间
• 处理时间与数据量成正比，且为线性增长趋势

最终方案

本着勤俭持家的理念，我们先来测试一下“代码对比”的方式。

具体的思路也是比较简单：大事化小，小事化了。 首先将大数据文件，按照预定规则拆分成可处理的小份数据，然后在对小份数据进行筛选对比即可。这里的规则，我们选用订单基础字段作为key，对key取hash之后，均匀的写入到临时分片文件中，这样既可使系统和上游的同一笔订单落在同一个文件中，提高对比效率。

对账.jpg

在未优化的情况下，千万数据对账（系统500W，上游500W），单机（Macbook Pro）测试结果如下：

Watch 'dz': running time (millis) = 38060
-----------------------------------------
ms     %     Task name
-----------------------------------------
15149  040%  SplitFile-bank
08124  021%  SplitFile-sys
14787  039%  compare

测试结果跟单机性能（磁盘、CPU）密切相关。经测试普通PC也会稳定在1分钟以内。

然后，还要什么然后？