【得物技术】浅谈资损防控

得物技术

墨衍会员 · AI 创作全网分发码龄6年

关注

原创 2021-07-04 14:53:29 2.7k 阅读 AI 写同款· GEO 优化 ›

什么是资损

资损通常来讲是指支付场景下的资金损失，这里可以从两个维度看

用户角度：多扣用户款导致用户资金损失，此问题一般需要通过客服等渠道反馈，可以把多的钱退给用户，但是很大程度上损失了用户体验；
公司角度：主要是多出金、多出货、多充值等情况，一般这种损失很难追回，这就是实打实的产生了资产损失。

比如对于一个电商业务可能涉及到上图各种业务，业务之间都存在下发、回调、消息传递等各种逻辑或者状态同步，如果其中由于一些交互操作丢失导致库存异常、资金结算换算异常、单据流程未结束异常、逻辑触发重复请求，并发控制处理不当等等，最终导致资产或资金的损失。

对于情况预防手段除了事前的一些列严格测试，事后分析的优化补救，也可以通过事中进行监控，得物在这方面就是通过自研的 DCheck 进行防控。

初识 DCheck

此系统由“交易 &稳定性”团队主导的，主要是希望及时的发现数据的问题，保障数据稳定的运行，尤其是涉及到资损的场景，为了做到实时有效的监控，在此背景下搭建了准实时核对系统 DCheck，此平台基于 Mysql 的 binglog 监控，以及 MQ 的订阅的信息流技术手段，通过配置触发条件、规则和任务运行以及告警，来确保各个业务上下游业务间的状态一致性，进出扣款金额计算后的准确性。

深入 DCheck

功能层级

架构逻辑

概念

主题：逻辑数据库或 MQ 订阅

事件：Update/ Insert 类型操作或 MQ 自定义消

子事件：事件所返回的数据的第一层过滤

脚本池：有 filter 和 check 两个继承方法，filter 处理二层数据过滤，check 业务上下游逻辑判断

规则：触发和检测核心执行部分

DCheck

对于此系统的功能和使用简单演示如下

核对配置

主题管理

TOPIC：库名
主题编码：表名
主题名称：中文的表名
MQ 实例地址: 对于 binlog 填*

事件管理

对于 binlog 而言，分成了 INSERT 和 UPDATE 两种，根据上主题配置自动生成无需创建。

子事件管理

清洗的数据的过滤层，此处在规则配置中，返回‘TRUE’的才会进入下一层，如：

if( obj.status.toInteger() == 10000 && (obj.type.toInteger() ==101 || obj.type.toInteger() ==301) ) return 'TRUE';

如果想所有都返回，就直接 return 'TRUE'。

脚本池管理

所有被执行脚本使用的是 groovy 进行编写的，主要是 BaseScript 实现 filter 和 check 两个方法，内部可以参考脚本库

Filter 经过事件过滤后需要脚本再进行二次过滤的操作，主要是一些不能简单从 donCleanData 进行判断，需要进行正向逆向获取其他数据，或是一些早为复杂的逻辑。
Check 验证逻辑处理方法，主要是就是进行上下游同步状态验证，复杂结果计算（尤其是进出帐扣款等方面）比较。

代码例子：

import com.alibaba.fastjson.JSON; import com.alibaba.fastjson.JSONObject; import groovy.util.logging.Slf4j; import org.springframework.stereotype.Service;  import javax.annotation.Resource;  /**  * DCheck:冷静期内-平台客服取消订单-退买家支付金额  */ @Slf4j @Service class CheckRefundPayForLess30min implements BaseScript {      @Resource     private OrderDevOpsApi orderDevOpsApi;      @Resource    DCheckApi dCheckApi;      @Resource     private PayServiceFeignClient payServiceFeignClient      String logTag = "TAG_CheckCrossAndOverSeaRefundPayForLess30min:{}"      // 1.关单时间-支付时间<30分钟     @Override     boolean filter(JSONObject doneCleanData) {         // 查询支付时间         String unionId = doneCleanData.getString("order_no");         String payTime = getOrderData(unionId,"payTime", DevOpsSceneEnum.FORWARD_PAY);         long modifyTime = doneCleanData.getDate("modify_time").getTime();          long diffTime = modifyTime - Long.valueOf(payTime)         if (diffTime < 30 * 60 * 1000){             return true;         }         log.info(logTag,"===>有符合数据进入Check")         return false;     }      @Override     String check(JSONObject doneCleanData) {         String subOrderNo = doneCleanData.getString("sub_order_no");         Result<List<String>> listResult = dCheckApi.queryPayNoBySubOrderNo(subOrderNo);         if(listResult == null || listResult.getData() == null) {             return "根据正向查询接口通过子订单号查询支付流水号数据为空";         }         if(listResult.getData().size() > 1){             return "根据正向查询接口通过子订单号查询支付流水号多条数据，请查看是否需要优化逻辑";         }                 String outPayNo = listResult.getData().get(0);         RefundQueryRequest refundQueryRequest = new RefundQueryRequest();         refundQueryRequest.setPayLogNum(outPayNo);         Result<List<RefundBillDTO>>  resp = payServiceFeignClient.queryRefundsByPayLogNum(refundQueryRequest);         // 判断支付查询数据是否为空，如果为空直接报数据错误，以及是否查询到了多条数据         if (resp == null || resp.getData() == null) {             return "上游数据为空:支付退款查询(根据支付流水号)";         }         else if (resp.getData().size() != 1) {             return "上游数据为多条请确认逻辑:支付退款查询(根据支付流水号)";         }          // 检查点逻辑判断1: 状态为打款成功         if (resp.getData().get(0).getStatus() !=2 ){             return "校验支付打款状态非2";         }          // 逻辑校验点2：交易退款和RPC查询的金额一致，否则告警         if (resp.getData().get(0).getAmount() != doneCleanData.getLong("amount")) {             return "校验交易退款金额和支付打款金额不一致";         }         return "SUCCESS";     }      // 数据库查询对应字段值     String getOrderData(String unionNo,String key,DevOpsSceneEnum devOpsSceneEnum){         // 内部方法省略....         return value;     } }

规则配置

规则配置为上述所有基础配置的组合以及真正的运行核心，主要两大块，基础信息和降级策略。

基础信息：子事件（支持搜索和多个选中）+ 脚本类（搜索选择） = 触发和执行逻辑

其他为辅助配置信息按照各自域和需求配置。

降级策略：

采样百分比：线上流量采样百分比，前期测试或者对业务有很大影响的需要控制流量，不能为 100%
首次延迟时间：触发执行延迟时间，在业务流程，数据同步有些会有些延迟，为了避免由于延迟导致的状态不同步问题，建议设置一定的延迟比例，一般 10 秒左右
最大超时时间和生效时间：规则有效时间配置

工具使用

核对异常

针对 check 异常的数据，一般首先会发到配置的告警飞书群和配置的个人，点击即可跳转到此页面，主要看错误的具体数据，经确认后是脚本或者部分数据问题的，优化后“重发”可以标记为处理，如果是确定是问题的，则定位“资损”问题。

Mock

由于本地脚本调用一些 RPC 接口，目前还没有好的办法能在本地进行 debug，所以就需要通过先配置规则后，使用 mock 进行调试，主要用到的是规则调试，选择指定的规则，搜索或者创造符合 dcheck 场景的 json 格式的请求参数，提交请求查看响应结果即可。

这里有个问题，因为 dcheck 内部逻辑对一些系统异常脚本做了统一处理，很多时候没法看到具体的原因，就是失败或者逻辑外通过，这就需要需要在脚本中多加些打印日志，然后通过日志平台去查看具体逻辑问题。

一些使用技巧

1. 规则配置技巧

规则中事件是可以多选的，所以对于事件不同，但 check 相同或者相似的脚本处理逻辑可以归并，减少规则维护量
触发数据可以在事件进行配置的，尽量少用脚本 filter 处理，代码一般处理需要非触发数据外逻辑

2. Groovy 的闭包使用

脚本数据处理有会有很多 list，key-value 的处理，可以充分利用 groovy 的闭包特性，大大简化 java 语言的复杂处理逻辑。

举例：如果如下数据格式的结果返回 objectList：

[{id=10086, refundNo=RE10086, orderNo=100888, userId=15206, bizType=110, payTool=0, payStatus=404,amount=100, feature=, isDel=0, createTime=2021-05-11 21:39:34.000, modifyTime=2021-05-11 21:39:34.000, moneyFrom=1, currency=, countryCode=},{id=10087, refundNo=RE10087, orderNo=100999, userId=15206, bizType=202, payTool=0, payStatus=404, amount=400, feature=, isDel=0, createTime=2021-05-11 21:39:34.000, modifyTime=2021-05-11 21:39:34.000, moneyFrom=1, countryCode=}]

1）filter 进行条件判断，可以使用 any

def filterResult = objectList.any{it.bizType in [110,119] && it.payStatus == 404};

return filterResult

2）check 获取某个符合条件的值，可以使用 find

def mount = objectList.find{ it.type=5}.amount

更多 groovy 特性可以参考文章：https://www.jianshu.com/p/5d30f1443aa6