风控系统实践之感: drools 和 redis 二

2024-04-15 07:15

1. 风控系统实践之感: drools 和 redis 二

根据目前风控系统运行情况来看,遇到如下的问题
  
 1. redis 中的key 太多,在存量卡号比较大的情况下,redis 中key的存储过于庞大。
  
 2. redis 本身RDB 和 AOF 的问题。 线上开启AOF 重写出差情况下,会阻塞redis 主线程。
  
 基于以上问题,我们发现redis 开启AOF 和 RDB 带来许多麻烦。第一点 是冷热key 的问题,redis中存储了大量的key,而这些key 是用来累计各种衍生变量的。但是其中很大一部分是冷key。这些key 其实可以置换到SSD 这种存储设备上的。
  
 因此为了解决冷热key 的问题,我们引入了额外的中间件 areospike。 冷热key的置换和一致性的维护,是比较困难的,何为冷key,可以热key呢?  我们没有严格按照冷热key的标准来做,我们根据业务来做。天,周,月 等累计或者统计,都是放在areospike 里面进行的。 但是天以内的小时级别的累计,因为要求实现滑动窗口,对准确性和实时性比较高, 因而延续redis 的方式去实现。那么对于风控中各种窗口的累计和维护变成如下的变动:
  
 1. areospike 统计 天, 周, 月 等纬度的累计,默认是一天长度的滚动窗口
  
 2. 24小时内的衍生变量计算,继续使用redis做滑动窗口的计算。
  
 针对第二问题,我们也没有发现线上产生这种原因具体是什么,但是可以怀疑的是
  
 线上单台redis 太大,有120G,如果AOF 重写出错,需要从头开始同步更多的数据。一边应用对redis 有大量的写操作,一边 redis 本身有AOF 大量重写。
  
 对于这种问题,我们没有找到本质原因,但是我们将120G redis 变成了 60G的大小,切成两台。同时只开了RDB。 问题就没有再出现过。
  
 对于risk 后面的规划是在实时风控那块变成Flink 模式。 批量风控目前hive/clickhouse 可以解决,系统还在逐步的演化。

风控系统实践之感: drools 和 redis 二