背景

随着业务规模的不断增长，产生了海量的业务数据，为了能够在这些业务数据中及时发现业务异常，我们需要一套自动化的业务一致性校验平台。它要能够实时发现线上业异常数据，及时间通知相关人员介入排查，以降低数据异常对用户和业务的影响。低成本接入各种场景数据校对。通过后台配置方式，录入校验规则信息。

方案设计

数据采集

通过采集 触发事件源 和 目标事件数据源 的数据，进行规则验证后，执行数据的临时存储。

事件源的订单

事件源分为触发事件源和目标事件源，为防止对业务系统产生影响，本平台不应直接在业务系统的数据库中进行查询，而通过解析数据库binlog来进行事件的获取。

不同校验任务的事件源应该独立，避免多任务间的相互影响。

每一个任务都需要同时对触发源和目标源进行监听，不同任务要使用不同的groupid，保证不同的任务都要消费相同的消息。每一个任务都相对独立，不受到其他任务的影响。

触发事件源监听处理

目标事件源监听处理

数据校验

实时或者延时触发校验，组合消息并进行规则校验，出现校验异常时

事件数据存储

采用Redis 缓存来作为数据临时存储。

延时任务队列：

使用Redis的Sorted sets 按照预计处理时间存储，以秒为单位，每秒一条数据，对应的值为这一秒钟产生的触发消息列表键名；

键名：bcp:delayjob:{jobid}

触发消息列表：

1秒一个列表，存储这1秒需要校验的触发事件数据列表，一次任务只取一次。根据当前业务规模，预估单个任务秒级别的消息量在1年应该少于100个。

目标消息：

目标消息使用单键存储，键名为任务编号+匹配字段（如订单编号）。验证时直接获取单键，过期时间为校验延时 * (重试次数+1)。资源开销比较可控，功能基本满足当前需要。

缺点：

只能通过配置触发消息和目标消息间匹配字段来进行消息的匹配，无法进行目标消息的筛选。

数据校验流程

业务模型

业务规则

异常数据日志

接口抽象

kafka数据格式

业务上线情况

订单完成

校验场景：运单完成后，校验订单状态是否完成。延迟5s，最多重试3次。

源数据匹配脚本：（运单）

目标数据匹配脚本：(订单)

校验执行情况

触发准确，与状态同步失败异常相对应，异常均能及时触发报警

订单取消退款

校验场景：订单取消后，校验是否产生退款交易流水。延迟10s，最多重试3次。

源数据匹配脚本：（订单，不校验代驾订单，因为代驾订单时后付费，取消订单时没有退款）

目标数据匹配脚本：(用户交易流水，家政退款流水备注无取消关键字，根据科目校验)

校验执行情况

能够及时发现取消订单无退款的情况，有一次因系统丢单导致无用户交易流水，订单取消时因无交易流水未退款，平台及时捕获到数据的一致性异常并由人工介入完成用户退款。

刚开始时校验有较多的误报，主要是代驾订单、家政订单取消退款流程和跑腿订单不一致，经过调整匹配脚本，现在已经没有误报了。

退款交易流水金额校验

校验场景：退款交易流水金额与支付流水金额比较，及时发现退款金额错误

源数据匹配脚本：（用户交易流水，退款交易流水）

目标数据匹配脚本：(用户交易流水，更新退款流水id)

数据校验脚本：（校验多条支付交易流水和退款交易流水的金额）

校验执行情况

为支持用户支付流水有多条的情况，升级了BCP服务，支持目标源多条数据的检查。上线后金额校验比较准确，未发现误报。

平台的后续发展方向

当前平台通过一段时间的运行，验证了方案的可行性，以及系统资源占用等情况。但是当前平台也有许多需要解决的问题。

数据匹配扩展

当前的数据匹配场景主要是数据跟随变化，A变化的同步B也必须要变化，如果没有变化就要报警。但是当前业务是变化了要报警，不变化是正确的，主要是为了防止并发，例如：运单抢单后，订单不能取消，如果订单取消就要报警。

异常数据处理

能够及时发现数据的一致性异常，但是缺乏处理手段，现在还是只能通过告警的方式由人工介入处理。

下一步要加强异常数据的后续处理功能的完善，任务支持配置异步消息队列将异常数据通过消息队列等其他方式同步给业务系统，由业务系统进行重试或数据同步。