風控核心子域——名單服務構建及挑戰

引言

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

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

風險型別

名單維度

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

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

名單服務的特點如下：

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

考慮到名單有時效性及效能要求，且名單資料結構整體簡單（多維度，單個維度儲存內容小），選擇 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/ >

若有收穫，就點個贊吧