引言
名單服務是風控架構中重要子域，對風險決策的性能、使用者體驗、成本管控、風險治理沉澱都有重要影響，本文将詳細介紹名單服務設計思路和實作。
背景
什麼是名單？
名單服務通常有幾個部分組成：
風險類型
- 黑名單：絕對會被拒絕的使用者。大部分是曆史資料清洗出來作弊或者破壞業務的使用者，這部分使用者對企業無價值且放之進入會破壞生态平衡
- 灰名單：灰名單上的客戶需要進一步稽核。這部分使用者可能存在某些風險，但是沒有明确的證據表明他們是“黑”的
- 白名單：這部分客戶是正常使用者，是企業數分人員基于曆史表現清洗出來的合規高價值使用者，可以直接放行
名單次元
- 主鍵：手機号、使用者ID、身份證号、IP、裝置辨別、wifi MAC位址等等
- 業務域：全域、業務子域、細分領域等等，這邊需要字典服務來枚舉出需要管控的粒度和場景
時間次元
名單是有一定的生效期的，不同的行為會導緻鎖定期不一樣，生效時間可以靈活設定
為什麼需要名單服務？
- 最易建構的決策能力：風控前期的建構是比較依賴名單決策的，政策數分人員通過曆史資料判定哪些是“壞使用者”，直接将其存儲到名單庫中，後續請求直接在第一道名單決策中踢出，而不需要執行後續政策在判定一次。政策相對名單來說是非常“重”的，且名單服務建構簡單便捷，省時省力。
- 性能考慮：名單判定一般是在決策流的第一道，試想，對企業服務來說，大部分使用者其實都是正常的，如果每個使用者的請求都過一遍政策，對成本是極大的浪費，同時對性能來說也是極大的挑戰。此時名單服務通過白黑名單，将大部分使用者直接決策出去，隻對不明确的客戶和有風險的客戶來做決策，極大地減少了開銷。
設計實作
名單服務的特點如下：
- 名單資料來源：可以是實時産生、離線跑批生産、營運人員手動批量導入等等，形式多樣
- 性能足夠好：屬于決策流入口必過服務之一，即最大流量沖擊，需要經得起峰值壓力，RT 要足夠小
- 穩定性：高性能同時還需要高品質保證，如果名單服務出問題，後果不堪設想，流量全部流放到下遊，可能會出現服務雪崩
- 品質保證：任何名單添加到名單庫中都需要重視，随意的添加可能會給企業帶來難以想象的損失，是以得有完備的稽核記錄及添加原因，最重要的是生效時間的設定
整體名單服務的資料流圖如下所示，重要節點會作明确說明：
實時鍊路名單查詢設計
考慮到名單有時效性及性能要求，且名單資料結構整體簡單（多元度，單個次元存儲内容小），選擇 Redis 存儲名單資料非常适合快速查詢，資料結構如下：
說明：
- 采用 Redis Hash 結構存儲資料
- 為何不用 TTL 來存儲過期時間？：一是 expire 最大過期時間不能超過 Integer.MAXVALUE 不能滿足長時間的過期訴求；二來 Redis 本身定位是緩存，不是永久存儲，即資料是可丢失的，需要自己保證服務的高可用
依賴于 Redis 叢集良好的性能，基本能滿足線上峰值高 QPS 查詢需求，且 RT 能很好的控制在 10 ms以内。如上所說就是要保障高穩定性需求，如何保障名單資料的高可用是首要問題。
高可用設計
Redis 本身定位是緩存，不能永久儲存資料，且叢集癱瘓或者資料部分缺失應對業務影響較小（能及時恢複的情況下，運維保障叢集的可用性），如下是高可用資料設計架構：
說明：
- T+1 Job 保證資料穩定：每天離線任務全量覆寫，從關系資料庫 PG/MySQL 中抽數 push 到 Redis 中即可
- Redis 叢集出問題：不管是老叢集重新開機還是更換到新叢集，先用 RDB 恢複資料，保證線上可用，再立即執行離線任務做精确覆寫（T日的資料丢失需要立即覆寫），考慮到讀寫同時進行可能會有問題，需要分叢集切流
同時需要關注多線程問題，同一個次元，在同一時間可能存在批量更新情況，尤其是離線任務恢複時，曆史資料會存在對一個次元多次更新問題，不考慮多線程問題可能會導緻資料被篡改。
資料安全審計
名單庫的風險點在于：随意地添加名單可能導緻“壞使用者”暢通無阻，“好使用者”無法在進入業務流程
名單的生産來源及定性原因不明确，線上在排查問題時也隻能幹瞪眼，為了能回溯名單操作，需要做到如下幾點：
- 寫日志：任何寫動作需要追加日志，且需要做持久換存儲，友善做名單時序資料分析
- 黑名單 & 白名單需要審計：尤其是線上單獨添加這種，必須指明原因且要對操作負責
- 跑批任務審計：離線任務或者算法推數等需要控量，否則在疊代更新過程中出現 BUG 問題，導緻名單資料猛增，後果不堪設想
異動監控
監控重中之重。
能第一時間感覺問題，監控的次元如下：
- 決策層面監控：灰、白、黑名單決策數量監控
- 中繼資料産出層面監控：任何名單猛增或猛跌都是需要去定性是否正常
- 拉黑踢白：沒有永久犯錯的人，也沒有永久的好人，名單之間的流動也需要關注
總結
名單服務在風控域中是最重要的子域之一，是風控流量的“網關”。名單庫對整個風控決策的穩定性，性能提升起到決定性影響。
同時名單服務也是“高危”的，如果使用不當，可能會給企業良好使用者帶來困擾，給那些“黑産”敞開門戶，需要做好資料稽核及異動監控。
往期精彩
- 性能調優——小小的log大大的坑
- 性能優化必備——火焰圖
- Flink 在風控場景實時特征落地實戰
歡迎關注公衆号：咕咕雞技術專欄
個人技術部落格：https://jifuwei.github.io/
若有收獲，就點個贊吧