1. sql核对
   exist insert select
   最简单的方式，也是问题比较多方式，对数据库压力比较大，数据特别多的时候，对账效率比较低。
2. redis核对
   set集合分别diff （inter）上游、下游数据
   比较好的方式，可以降低数据库压力，redis方便根据数据量做水平扩展。
3. sprak核对
   采用流式运算进行比对；（具体做法待扩展）

差错处理

在一般系统中，差错处理分为两种，一种人工来处理，一种系统自动来处理。
  人工处理一般两个操作：平账和勾兑，勾兑一般处理的是单边情况，比如由于系统bug出现的单边问题，经由人工溯源修复bug之后，相关业务人员即可在对账后台将该条数据进行勾兑。
  系统自动处理一般为：自动补单和驱动下游流程完成两种方式。主要有如下情况：
下游单边（银行单边）情况
  业务未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。
  一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
上游单边（企业单边）情况
  业务已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。
  在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。
金额不等情况
  业务已支付，支付渠道已支付，但是金额不同，这个需要人工核查。

对账统计

根据对账处理结果，统计的数据由：汇总总条目、汇总总金额、汇总差异结果、汇总单边结果、汇总处理结果。
  业务和财务关系的统计的相关信息有：对账完成时间、对账是否成功、平账的金额和订单数、差错的金额和订单数、缓存池金额和订单数等。

核心对账优化

上文模块设计有提到核心对账的多种实现思路，这里推荐的两种：

1. redis 实现
2. sprak 实现
   具体实现过程会在后续博文中详细介绍。

对账系统数据库模型

按以上设计模型，具体数据模型如下介绍。

底稿数据表

• 各个上游数据、下游数据抓取、解析的底稿数据 。
• 不只两张表，由具体业务决定；数据量比较大，一般按日期水平分表，按实际业务考虑要不要垂直分表。

清洗表

• 从各个上游数据、下游数据的底稿数据取部分字段。
• 不只两张表，由具体业务决定；数据量比较大，一般按日期分表。

对账结果表

• 正常表
  用来存放对上账的数据(即对账结果正常的数据，一般数据量比较大，需要按日期分表)
• 异常表
  用来存放对不上账的数据（上游单边、下游单边、金额不等）。

对账汇总表

即对对账数据的汇总

技术相关表

定时配置、账户配置、异常信息等等相关表