📚 课程目录第3章技术栈选型

3. 技术栈选型：流式计算框架、规则引擎、数据库与消息队列

信用额度定价的流式决策链路对延迟、吞吐、状态一致性与规则可维护性有极高要求。本章从四个核心维度——流式计算框架、规则引擎、数据库、消息队列——逐一对比候选技术，给出选型理由与组合建议。

流式计算框架是决策链路的数据中枢，负责实时接入事件、关联用户画像、调用规则并输出定价结果。候选方案为 Apache Flink 与 Spark Streaming。

对比维度	Apache Flink	Spark Streaming
计算模型	原生流式（逐条处理）	微批次（Mini-Batch）
延迟	亚秒级（毫秒级）	秒级（通常 1~5 秒）
状态管理	内置 Keyed State、ValueState、MapState，支持 RocksDB 状态后端	需借助外部存储或 DStream 状态算子，能力较弱
Exactly-Once 语义	端到端支持（两阶段提交 + 检查点）	依赖外部 sink 实现，复杂度高
事件时间处理	原生支持 Watermark + 窗口	需手动处理乱序，精度受限
与规则引擎集成	ProcessFunction 可灵活调用外部服务	需在 foreachRDD 中同步调用

选型结论：信用额度定价要求毫秒级响应与精确一次的状态一致性，Flink 的原生流式模型、丰富状态 API 和事件时间支持更匹配业务需求。Spark Streaming 更适合吞吐优先、延迟容忍度较高的批量特征计算场景。

信用额度定价涉及大量条件组合（收入区间、历史逾期、多头借贷、行业系数等），规则引擎负责将复杂业务逻辑从代码中解耦。候选方案为 Drools 与 EasyRules。

对比维度	Drools	EasyRules
规则语法	DRL 专用语言，支持 when-then、salience、agenda-group	Java 注解 + 链式 API，轻量
推理能力	前向链、后向链、Rete 网络优化	顺序匹配，无复杂推理
规则数量	支持数千条规则，性能稳定	适合百条以内简单规则
动态更新	KIE 扫描器支持热加载	需重启或自定义刷新
与 Flink 集成	需封装为独立服务或嵌入 ProcessFunction	轻量嵌入，适合简单场景

选型建议：金融风控场景规则数量通常超过 200 条，且需要动态调整（如节假日提额、新客优惠），Drools 的 Rete 网络与热加载能力更合适。EasyRules 可用于简单的准入规则或白名单过滤，作为 Drools 的前置补充。

流式决策链路需要同时满足低延迟缓存与可靠持久化两个目标，单一数据库无法兼顾。采用 Redis + MySQL 组合是业界最佳实践。

存储层级	技术选型	核心用途	数据量级
缓存层	Redis Cluster	用户实时额度、日累计、规则缓存	百万级 key
持久层	MySQL 8.0 + 读写分离	规则配置、定价矩阵、审计日志	千万级行

注意：Redis 不保证强一致性，在宕机或主从切换时可能丢失少量数据。因此所有定价结果必须异步写回 MySQL，Redis 仅作为性能加速层，不可作为唯一数据源。

消息队列在流式链路中承担事件总线角色，连接数据采集、Flink 计算、结果分发。候选方案包括 Kafka、RocketMQ、RabbitMQ。

最终技术栈组合：

流式计算：Apache Flink（原生流式 + 状态管理）

规则引擎：Drools（Rete 网络 + 热加载）

数据库：Redis Cluster（缓存层）+ MySQL 8.0（持久层）

消息队列：Apache Kafka（事件总线 + 结果分发）

下表汇总各组件选型理由与核心关注点：