对账系统技术架构

 

      很多时候会碰到新业务上线之后，发现由于程序bug导致一些脏数据，但是这些脏数据并不会立即告诉你我这边出问题了，你赶紧修复或者回滚。往往是等若干小时之后，陆续有用户反馈，数据或应用出现问题了，然后通知客满，客满再反馈给开发同学。

      在做对账的时候要考虑这两点：第一是每一次资金入账都要符合预期，要能够准确识别出来哪些是异常入账并进行拦截，进入人工审核。另外还需要增加一种事后对账，确保上下游系统的数据是完全一致的。要做到笔笔清。目前还缺少入账实时对账这块的风控。

引入对账之后的流程变更 

流程图：

简单理解：在做入账操作之前先做一次对账处理。看下数据是否合理的。

实时对账业务架构

引入一个对账中心，这个对账中心要做的事情就是结算系统的数据与业务数据进行对账。判断当前这笔结算是否有风险。

结算系统根据对账中心的返回结果，决策后续流程。如果对账异常，那么进行冻结，否则，进行结算入账。

批量对账业务架构

说明：

1. 对账中心把每一个对账需求都看做一个对账任务，每一个对账任务采用数据收集器+对账处理器的方式进行对账处理。
2. 批量对账的触发方式采用dts定期触发，可以在dts中配置对账的时间范围。
3. 对账任务被触发后，调用数据收集器拉取业务系统和结算系统流水数据。数据收集器采用并发方式拉取对账数据，以减少数据查询时间。数据查询完成后，交由对账任务处理器进行对账处理。
4. 对账任务处理器采取双向对账的方式进行对账，即先以业务系统流水为基准进行对账，然后，再以结算系统流水为基准进行对账。另外，为了防止对账时间范围临界处的流水可能拉取不到的问题，在拉取批量对账数据时，向前向后多拉取了10s 范围的数据，我们称为临界区数据。例如，在进行t+1日对账时，我们拉取的时间范围就是[t-1 23:59:50, t+1 00:00:10]。但是,对账的基准数据仍然是[t 00:00:00, t 23:59:59]，只不过查询数据时会覆盖到临界区数据。
5. 对账任务每次执行都会生成一个批次号，并记录对账状态。如果对账失败，则要把对账失败的记录也插入DB，便于后续排查。

风控系统

风控系统比较常见的一个架构图：

简单列举几个末端结算相关的风控规则：

1、提现金额到达一个指定的阀值的时候报警或进入人工审核平台

2、结算金额范围校验

3、异常数据监控

两个引擎

风控规则引擎用来执行风控实时规则，为上游提供实时的风控风险识别能力的输出。

 

风控离线模型引擎用来运行离线算法模型，产出的结果为风控规则引擎提供决策依据。从数据仓库中获取所需要的指标，产出的结果也会沉淀到数据仓库中。

后续末端结算域的风控系统设计上也是可以参考下这块的设计。包括风控实时规则，离线的可以基于离线数据进行运算风控模型。进一步来讲，可以将刷单风控、等这些功能也做进来。

抽象风控监控模型