对账，是一个支付系统的必备功能。
如何做到性价比最（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分钟以内。
然后，还要什么然后？
