实时计算特征，规则引擎如何应用？——从业务痛点出发的网站化思路

一、业务痛点：为什么传统方式难以支撑？

• 策略人员“小手一滑”Excel 中几个维度两两组合。瞬间产生几百个特征，开发周期被拉长。
• SQL 统计模式瓶颈新业务需要 500 个特征。纯 SQL 或代码开发至少要 5 天业务验证又要额外时间，导致从需求到上线常常拖延半月甚至一个月。
• 决策响应慢特征计算耗时直接影响风控决策时延，支付场景下毫秒级延迟都可能造成巨大损失。
• 规则引擎与特征隔离策略人员与规则开发人员长期脱节。改动依赖开发，易出现“认错孩子”的问题。
• 实时性要求不高的方案无法满足支付风控: 仅适用于信贷等低实时场景，在高频交易中存在部署效率和执行耗时双重隐患。

二、解决思路：实时特征计算网站化

我们不再区分“离线数据”和“实时数据”，而是把所有特征统一纳入实时增量计算程序。说到主要目标是，让特征的生成、更新与查询都在毫秒级完成。策略人员可以即時調整規則而無需等待開發。

三、网站整体架构

业务程序 → TxnFeatureService → FeatureDataSunkTask
│
├─ 幂等判断
├─ 异步并发处理
├─ 策略路由
├─ 执行累计算法
├─ 写入 Redis
├─ 主维度值监控记录
├─ 历史快照数据落库
└─ 设置幂等标记
Redis 高速缓存层 ←→
监控数据 → Kafka / DB → 数据审计 & 故障追溯

四、主要概念与数据模型

• 特征**：在固定时间窗口内基于主维度和从维度对业务事件进行累计的值。
• Main‑value / Slave‑value**：如 user_id、device_id。
• 累计方式枚举 FeatureCumTypeEnum**：TTL、CD、CM、CY、FVR。
• 计算方式**：SUM、COUNT、G、MIN、MAX。
• Redis Key 格式】：{featureCode}:{masterValue}
• Value 结构】：JSON Map

五、关键模块详解

1. 特征累计服务接口 TxnFeatureService

writeFeature

• txnId**、**txnTime**、**eventDataList**.
• 接收请求后直接触发异步处理流程，立即返回给调用方。

2. 数据处理任务 FeatureDataSunkTask

1. 校验事件数据非空。不过，
2. 异步保存原始事件流数据到监控存储.
3. 遍历事件列表：
   • 幂等判断 Redis Key = pay:rcs:feature:handle:{txnId}:{featureCode}
   • 若已处理则跳过；否则提交 CompletableFuture 任务到线程池；，

     通过 FeatureDataSunkFactory 按 cumType 获取对应策略；执行 getFeatureData——读取 Redis → 过滤过期 → 追加新值 → 写回 Redis；说起来，写入主维度值监控记录；保存历史快照，设置幂等标记；

3. 策略模式层 AbstractFeatureDataSunkService + 工厂 FeatureDataSunkFactory

• getCumType 作为路由键；getFeatureData 需子类实现具体累计算法.

五种内置策略：TTL、自然日、自然月、自然年、永久累计.

工厂采用 Spring @PostConstruct 自动注册所有 AbstractFeatureDataSunkService Bean。零配置 新增方式只需添加新实现类并打上 @Service 注解.

4. 辅助工具类 FeatureRedisKeyBuilder & FeatureTimeOutBuilder

• 根据 cumType/expireNum/expireType 动态算出缓存过期时间及窗口边界.

5. 监控层 FeatureMonitorSinkService

• 所有监控数据异步落库至 Kafka / DB，便於審計與問題追溯。 "，

  六 、 性能優化關鍵點

  "
  '線程池配置' : payRcsFeatureSunkTp + payRcsFeatureMonitorTp;core = CPU×2;queue 建議 -，拒絕政策 CallerRunsPolicy;不过，l i>'併發處理' : 每筆事件獨立 CompletableFuture。allOf.join，l i>'幂等控制' : Redis Key pay:rcs:feature:handle:{txnId}:{featureCode}。處理前檢查存在則跳過,處理完設定 "" TTL=5min;l i>'Redis 優化' : AOF+RDB 持久化。maxmemory 上限,淘汰策略 volatile-ttl;l i>'批量寫入' : Pipeline 減少網路開銓,批量落庫監控數據降低 DB 壓力;"

  七 、 擴展性設計

  "
  1. 新增累計方式 : ol type='a'> li>繼承 AbstractFeatureDataSunkService; li>實現 getCumType 自訂標識； li>實現 getFeatureData 自訂算法；li>加 @Service，Spring 自動掃描註冊；li>在 FeatureCumTypeEnum 中補充對應枚舉值；怎么说呢，ol>
  2. 新增計算方式 : ul type=disc'> li>在現有策略內依據 calateType 分支處理 SUM / COUNT / G / MIN / MAX；li>或單獨建立專門的 Strategy 類；" "

  八 、 最佳實踐與使用建議

  "
  主維度選擇 ul> li>選高頻查詢維度作為主維度；" < l i>從維度選擇 ul> li>需要細分統計的維度作為從維度；" < l i>時間窗口設定 ul> li>TTL 模式依業務場景設定合理窗長；li>自然日/月/年適合週期性統計；" < l i>計算方式選擇 ul> li>COUNT 用於次數統計；li>SUM 用於金額累積；li>G 用於平均值，" " " "

  " h2 id='heading-''>九 、 小結與價值 "

  " 基於 Redis 的毫秒級讀寫 + 增量式 Flink/Kafka，支撐每秒數萬筆特徵更新與查詢。"> high availability> 異步處理 + 島式故障隔離 + HBase 備份，單點失敗不影響整體決策鏈。"> easy extension> 策略模式＋工廠自動註冊，新增累計方式零改造。"> full traceability> 完整的監控數據落庫支持審計與問題追溯。"> idempotent safety> Redis 原子幂等標記防止重複累計。" ol "
  
  

  "

  >適用場景 << ul type= disc ' Li 風險反欺詐 '; Li 用戶行為分析 ; Li交易監控 ; Li營銷活動 ； Li資源配額 ； ul "

  " h2 id='heading-''>技術棧概覽 "

  ' ' ' ' ' ' ' ' table "

  " p>>總結 << 通過 實時特徵計算网站我們把從「Excel 小手一滑」到「上線需半個月」的痛苦循環轉變為「分鐘級配飾 + 毫秒級決策」。規則引擎不再是開發人員的專屬領域，而是可以由風險策略人員直接驅動的即時決策引擎——這才是真正貼近業務痛點、提高競爭力的解決方案。"