3. 技术选型与工具栈：Kafka、Flink、Redis、模型服务框架、监控工具

实时异常交易检测系统对数据管道、计算引擎、状态存储、模型推理和可观测性提出了严苛要求。本章从生产级稳定性、毫秒级延迟、高吞吐和运维复杂度四个维度，逐一论证核心组件的选型理由。

3.1 数据管道：Apache Kafka

Kafka 作为分布式消息队列，是实时数据流的“中枢神经”。在异常交易场景中，它承担了交易事件采集、削峰填谷和多消费者解耦的职责。

3.2 流计算引擎：Apache Flink

Flink 是实时异常检测的核心计算引擎，负责特征提取、窗口聚合、规则匹配和模型调用编排。

• 事件时间语义：支持乱序事件处理，水位线机制可容忍交易延迟到达。
• 状态管理：RocksDB 状态后端支持 GB 级用户画像与历史特征存储。
• Exactly-Once 保证：端到端一致性，避免重复计费或漏检。
• CEP 库：复杂事件处理可直接定义“短时间内多笔大额交易”等模式。

// Flink 作业核心骨架（Java）
DataStream<Transaction> transactions = env
    .addSource(new FlinkKafkaConsumer<>("transactions", ...))
    .assignTimestampsAndWatermarks(WatermarkStrategy.<Transaction>forBoundedOutOfOrderness(Duration.ofSeconds(5)));

// 特征提取与模型调用
transactions
    .keyBy(tx -> tx.getUserId())
    .process(new FeatureExtractionAndModelInvocation())
    .addSink(new AlertSink());

3.3 状态缓存与特征存储：Redis

Redis 在实时异常检测中承担“热数据层”角色，存储用户短期行为特征、黑名单、规则缓存和模型推理中间结果。

3.4 模型服务框架：Triton Inference Server 与 MLflow

模型服务框架需要同时满足低延迟推理和模型生命周期管理两个需求。本案例采用 Triton + MLflow 组合方案。

3.4.1 Triton Inference Server

• 多框架支持：PyTorch、TensorFlow、ONNX、XGBoost 模型可部署在同一进程。
• 动态批处理：自动合并多个请求为 batch，提升 GPU 利用率。
• 模型并发：同一模型可部署多个实例，利用 GPU 流并行推理。
• Prometheus 指标暴露：原生输出推理延迟、吞吐、队列长度。

3.4.2 MLflow

• 模型注册中心：管理模型版本、阶段（Staging / Production）。
• 实验追踪：记录训练参数、指标、模型 artifact。
• 一键部署：通过 MLflow 模型服务或导出为 Triton 格式。

# MLflow 注册模型示例
import mlflow.pyfunc

class AnomalyModel(mlflow.pyfunc.PythonModel):
    def predict(self, context, model_input):
        # 调用 Triton 客户端或本地推理
        return model_input.apply(lambda row: detect(row), axis=1)

mlflow.pyfunc.log_model(
    artifact_path="anomaly_model",
    python_model=AnomalyModel(),
    registered_model_name="TransactionAnomalyDetector"
)

3.5 监控与可观测性：Prometheus + Grafana

实时异常交易系统必须对数据延迟、模型推理耗时、作业健康度进行秒级监控。

3.6 整体技术架构图

下图展示了各组件之间的数据流与依赖关系：

3.7 选型总结矩阵

下表从 6 个关键维度对技术栈进行最终评分（1-5 分，5 分为最优）：