风控核心子域——名单服务构建及挑战-526互联

引言

名单服务是风控架构中重要子域，对风险决策的性能、用户体验、成本管控、风险治理沉淀都有重要影响，本文将详细介绍名单服务设计思路和实现。

名单服务通常有几个部分组成：

风险类型

名单维度

时间维度
名单是有一定的生效期的，不同的行为会导致锁定期不一样，生效时间可以灵活设置

最易构建的决策能力：风控前期的构建是比较依赖名单决策的，策略数分人员通过历史数据判定哪些是“坏用户”，直接将其存储到名单库中，后续请求直接在第一道名单决策中踢出，而不需要执行后续策略在判定一次。策略相对名单来说是非常“重”的，且名单服务构建简单便捷，省时省力。
性能考虑：名单判定一般是在决策流的第一道，试想，对企业服务来说，大部分用户其实都是正常的，如果每个用户的请求都过一遍策略，对成本是极大的浪费，同时对性能来说也是极大的挑战。此时名单服务通过白黑名单，将大部分用户直接决策出去，只对不明确的客户和有风险的客户来做决策，极大地减少了开销。

名单服务的特点如下：

整体名单服务的数据流图如下所示，重要节点会作明确说明：

考虑到名单有时效性及性能要求，且名单数据结构整体简单（多维度，单个维度存储内容小），选择 Redis 存储名单数据非常适合快速查询，数据结构如下：

说明：

采用 Redis Hash 结构存储数据
为何不用 TTL 来存储过期时间？：一是 expire 最大过期时间不能超过 Integer.MAXVALUE 不能满足长时间的过期诉求；二来 Redis 本身定位是缓存，不是永久存储，即数据是可丢失的，需要自己保证服务的高可用

依赖于 Redis 集群良好的性能，基本能满足线上峰值高 QPS 查询需求，且 RT 能很好的控制在 10 ms 以内。如上所说就是要保障高稳定性需求，如何保障名单数据的高可用是首要问题。

Redis 本身定位是缓存，不能永久保存数据，且集群瘫痪或者数据部分缺失应对业务影响较小（能及时恢复的情况下，运维保障集群的可用性），如下是高可用数据设计架构：

说明：

T+1 Job 保证数据稳定：每天离线任务全量覆盖，从关系数据库 PG/MySQL 中抽数 push 到 Redis 中即可
Redis 集群出问题：不管是老集群重启还是更换到新集群，先用 RDB 恢复数据，保证线上可用，再立即执行离线任务做精确覆盖（T 日的数据丢失需要立即覆盖），考虑到读写同时进行可能会有问题，需要分集群切流

同时需要关注多线程问题，同一个维度，在同一时间可能存在批量更新情况，尤其是离线任务恢复时，历史数据会存在对一个维度多次更新问题，不考虑多线程问题可能会导致数据被篡改。