风控系统实践之感: 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 可以解决，系统还在逐步的演化。