風控核心子域——名單服務構建及挑戰-有解無憂

引言

名單服務是風控架構中重要子域，對風險決策的性能、用戶體驗、成本管控、風險治理沉淀都有重要影響，本文將詳細介紹名單服務設計思路和實作，

名單服務通常有幾個部分組成：

風險型別

名單維度

時間維度
名單是有一定的生效期的，不同的行為會導致鎖定期不一樣，生效時間可以靈活設定

最易構建的決策能力：風控前期的構建是比較依賴名單決策的，策略數分人員通過歷史資料判定哪些是“壞用戶”，直接將其存盤到名單庫中，后續請求直接在第一道名單決策中踢出，而不需要執行后續策略在判定一次，策略相對名單來說是非常“重”的，且名單服務構建簡單便捷，省時省力，
性能考慮：名單判定一般是在決策流的第一道，試想，對企業服務來說，大部分用戶其實都是正常的，如果每個用戶的請求都過一遍策略，對成本是極大的浪費，同時對性能來說也是極大的挑戰，此時名單服務通過白黑名單，將大部分用戶直接決策出去，只對不明確的客戶和有風險的客戶來做決策，極大地減少了開銷，

名單服務的特點如下：

整體名單服務的資料流圖如下所示，重要節點會作明確說明：

考慮到名單有時效性及性能要求，且名單資料結構整體簡單（多維度，單個維度存盤內容小），選擇 Redis 存盤名單資料非常適合快速查詢，資料結構如下：

說明：

采用 Redis Hash 結構存盤資料
為何不用 TTL 來存盤過期時間？：一是 expire 最大過期時間不能超過 Integer.MAXVALUE 不能滿足長時間的過期訴求；二來 Redis 本身定位是快取，不是永久存盤，即資料是可丟失的，需要自己保證服務的高可用

依賴于 Redis 集群良好的性能，基本能滿足線上峰值高 QPS 查詢需求，且 RT 能很好的控制在 10 ms 以內，如上所說就是要保障高穩定性需求，如何保障名單資料的高可用是首要問題，

Redis 本身定位是快取，不能永久保存資料，且集群癱瘓或者資料部分缺失應對業務影響較小（能及時恢復的情況下，運維保障集群的可用性），如下是高可用資料設計架構：

說明：

T+1 Job 保證資料穩定：每天離線任務全量覆寫，從關系資料庫 PG/MySQL 中抽數 push 到 Redis 中即可
Redis 集群出問題：不管是老集群重啟還是更換到新集群，先用 RDB 恢復資料，保證線上可用，再立即執行離線任務做精確覆寫（T 日的資料丟失需要立即覆寫），考慮到讀寫同時進行可能會有問題，需要分集群切流

同時需要關注多執行緒問題，同一個維度，在同一時間可能存在批量更新情況，尤其是離線任務恢復時，歷史資料會存在對一個維度多次更新問題，不考慮多執行緒問題可能會導致資料被篡改，

名單庫的風險點在于：隨意地添加名單可能導致“壞用戶”暢通無阻，“好用戶”無法在進入業務流程

名單的生產來源及定性原因不明確，線上在排查問題時也只能干瞪眼，為了能回溯名單操作，需要做到如下幾點：

監控重中之重，

能第一時間感知問題，監控的維度如下：

名單服務在風控域中是最重要的子域之一，是風控流量的“網關”，名單庫對整個風控決策的穩定性，性能提升起到決定性影響，

同時名單服務也是“高危”的，如果使用不當，可能會給企業良好用戶帶來困擾，給那些“黑產”敞開門戶，需要做好資料審核及異動監控，

歡迎關注公眾號：咕咕雞技術專欄
個人技術博客：https://jifuwei.github.io/ >

若有識訓，就點個贊吧

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/542814.html

標籤：其他