4. 实时流处理引擎：Apache Flink/Spark Streaming 选型与架构设计
说到实时流处理，很多朋友第一反应就是「选 Flink 还是 Spark Streaming？」。这个问题我几乎在每个项目启动会上都会被问到。说实话，没有银弹。但如果你让我给个个人建议——交易监控系统，我倾向 Flink。为什么？往下看。
4.1 两大引擎的核心差异
先别急着选型，我们得搞清楚它们本质上的区别。说白了，这是两种不同的处理哲学。
| 维度 | Apache Flink | Spark Streaming |
|---|---|---|
| 处理模型 | 真正的逐条流处理 | 微批次（Micro-batch） |
| 延迟 | 毫秒级 | 秒级（通常 100ms-10s） |
| 状态管理 | 原生强状态支持 | 依赖外部存储 |
| 精确一次语义 | 内置支持 | 需要额外配置 |
| 事件时间处理 | 天生支持 | 支持但较复杂 |
嗯，这里要注意。交易监控对延迟极其敏感。你想想看，一笔异常交易晚发现 5 秒钟，可能几十万就没了。我在项目中遇到过因为 Spark Streaming 的微批次特性导致风控报警延迟的情况，后来切到 Flink 才解决。
4.2 为什么交易监控首选 Flink
我个人习惯把交易监控的需求拆成三个核心点：
- 低延迟：从交易发生到告警，最好控制在 200ms 以内
- 状态一致性：账户余额、交易次数这些状态不能丢，也不能错
- 乱序处理：网络延迟、系统时钟不同步，事件乱序是家常便饭
Flink 在这三点上都有天然优势。它的 事件时间（Event Time） 机制和 Watermark 设计，就是专门解决乱序问题的。我曾经在一个跨境支付项目中，交易数据因为跨时区导致时间戳乱序严重，用 Flink 的 Watermark 策略轻松搞定。
核心观点：Flink 的「逐条处理 + 事件时间」模型，天然适合交易监控这种对时序敏感的场景。Spark Streaming 的微批次更适合离线特征计算或非实时报表。
4.3 Flink 交易监控架构设计
好了，选定了 Flink，接下来怎么搭架构？我画了一张图，你看一眼就明白了。
这个架构图里，我特别想强调两个点：
4.4 关键设计：状态管理与 Checkpoint
交易监控里，状态管理是灵魂。比如统计「过去 5 分钟某用户的交易次数」，这就是一个状态。Flink 的 ValueState 和 MapState 用起来非常顺手。
// 示例：统计用户过去5分钟的交易次数
public class TradeCountFunction extends KeyedProcessFunction<String, TradeEvent, Alert> {
private ValueState<Long> countState;
private ValueState<Long> timerState;
@Override
public void open(Configuration parameters) {
ValueStateDescriptor<Long> descriptor =
new ValueStateDescriptor<>("tradeCount", Types.LONG);
countState = getRuntimeContext().getState(descriptor);
}
@Override
public void processElement(TradeEvent event, Context ctx, Collector<Alert> out) throws Exception {
Long count = countState.value();
if (count == null) count = 0L;
count++;
countState.update(count);
// 超过阈值触发告警
if (count > 10) {
out.collect(new Alert(event.getUserId(), "高频交易告警"));
}
}
}
避坑指南：我曾经因为 Checkpoint 间隔设置太短（1秒），导致生产环境频繁全量快照，把 HDFS 打爆了。建议交易场景设置 10-30 秒的 Checkpoint 间隔，配合增量 Checkpoint 使用。
4.5 选型决策树
如果你还在纠结，我给你一个简单的决策方法：
- 延迟要求 < 500ms → 选 Flink（没得商量）
- 延迟要求 1-5 秒 → 两者都可以，看团队技术栈
- 已有 Spark 生态 → 可以考虑 Spark Streaming，但要做好延迟妥协
- 需要复杂事件处理（CEP） → Flink CEP 库比 Spark 成熟得多
警告：不要为了「统一技术栈」强行用 Spark Streaming 做毫秒级交易监控。我见过一个团队因为这个选择，最后不得不花三个月重构。技术选型要尊重业务需求，而不是工程师的偏好。
4.6 实战中的几个坑
最后分享几个我踩过的坑：
- Watermark 设置太激进：曾经设置 100ms 的 Watermark 延迟，结果乱序数据大量被丢弃。建议交易场景设置 2-5 秒的容忍度。
- 状态后端选错：小集群用 MemoryStateBackend 没问题，但生产环境一定要用 RocksDBStateBackend，否则 OOM 教你做人。
- 并行度拍脑袋：我见过有人把并行度设成 1000，结果 Kafka 分区才 12 个。记住：Source 并行度 ≤ Kafka 分区数。
嗯，关于 Flink 和 Spark Streaming 的选型与架构设计，今天就聊这么多。记住一句话：交易监控没有银弹，但 Flink 是最接近银弹的那个。