第一章 流计算基础与金融场景概述
1.1 实时流计算到底是什么？
说实话，很多人一听到「流计算」就觉得很高大上。其实没那么玄乎。
流计算，说白了就是「数据一边来，一边算」。跟传统批处理不一样——批处理是先把数据存起来，等攒够了再统一算。流计算呢？数据到了就处理，毫秒级出结果。
我刚开始接触这个领域时，也犯过迷糊。记得有一次在银行做风控项目，业务方问我：「你们这个流计算，跟数据库的触发器有啥区别？」嗯，这个问题问得好。触发器是数据库内部的事件机制，而流计算处理的是跨系统、跨数据源的实时数据流，场景完全不同。
实时流计算的核心特征，我总结为三点：
- 低延迟：数据从产生到处理完成，通常在毫秒到秒级
- 持续计算：数据流是无穷的，计算引擎需要7×24小时运行
- 状态管理：很多计算需要记住历史数据，比如统计过去5分钟的成交笔数
核心要点：流计算不是简单的「数据来了就处理」，而是要在无穷数据流上做有状态的计算，同时保证结果的正确性。
1.2 金融场景的特殊性
金融场景对实时计算的要求，比互联网场景苛刻得多。为什么？因为钱的事，容不得半点马虎。
我个人在金融科技领域摸爬滚打了七八年，踩过的坑不少。金融场景的特点，我归纳为以下四个维度：
| 维度 | 要求 | 典型场景 |
|---|---|---|
| 延迟 | 毫秒级，通常<10ms | 高频交易、实时风控 |
| 可用性 | 99.99%以上，全年停机<1小时 | 支付系统、行情推送 |
| 一致性 | 精确一次（Exactly-Once） | 资金清算、对账 |
| 合规性 | 数据可审计、可回溯 | 监管报送、反洗钱 |
你想想看，一个支付系统如果因为流计算故障导致重复扣款，那后果有多严重？我曾经处理过一个线上事故，就是因为状态后端配置不当，导致交易流水重复处理，最后花了整整两天才把账调平。从那以后，我对一致性保证就格外敏感。
1.3 金融场景的典型架构
先看一张图，这是我画的一个典型金融实时计算架构：
这张图我画了很多遍，每次给新人培训都会拿出来讲。你看，数据从左边进来，经过消息中间件缓冲，再到流计算引擎处理，最后输出到各个下游系统。每一层都有可能出现故障，这也是我们这门课要重点讲的内容。
1.4 常见故障类型概览
做实时流计算，说白了就是跟各种故障打交道。我根据过往经验，把金融场景下的常见故障分成了五类：
- 数据倾斜：某个分区的数据量特别大，导致其他节点闲着，这个节点累死。我在一个行情处理项目中遇到过，某只热门股票的交易量是其他股票的100倍，结果那个节点直接OOM了。
- 状态不一致：Checkpoint失败或者恢复时状态错乱，导致计算结果出错。嗯，这个坑我踩过不止一次。
- 背压问题：数据生产速度大于消费速度，导致整个链路阻塞。说白了就是「吃不下」了。
- 延迟抖动：偶尔的GC停顿或者网络波动，导致处理延迟突然飙升。高频交易场景下，延迟从5ms跳到50ms，可能就是几百万的损失。
- 数据丢失或重复：Exactly-Once语义没配置好，导致数据要么丢了要么重复处理了。
⚠️ 特别注意：金融场景下，数据一致性问题是最高优先级的故障。宁可延迟高一点，也不能算错账。我曾经见过一个团队为了追求低延迟，把Checkpoint间隔设得太长，结果节点挂了之后恢复时丢了一大段数据，最后对账对了一周。
1.5 故障排查的思维框架
遇到故障不要慌，先问自己三个问题：
- 现象是什么？——延迟高了？数据丢了？还是结果不对？
- 影响范围多大？——单个任务？整个集群？还是所有业务？
- 根因可能在哪？——代码逻辑？配置参数？还是基础设施？
我个人习惯用「分层排查法」：先看监控告警，再看日志，然后看指标，最后才看代码。很多新手一上来就翻代码，其实效率很低。你想想看，如果是因为Kafka集群挂了导致数据进不来，你翻Flink代码有什么用？
💡 小技巧：建议在项目初期就把监控体系搭好。至少要有：任务延迟监控、数据流量监控、Checkpoint状态监控、GC监控。这些监控在故障排查时能帮你节省大量时间。
1.6 本章小结
这一章我们聊了流计算的基本概念，金融场景的特殊要求，以及常见的故障类型。说白了，金融实时计算就是一场「既要又要还要」的游戏——既要低延迟，又要高可用，还要数据一致性。这三者之间本身就存在矛盾，需要我们在架构设计和参数调优时做权衡。
后面的章节，我会结合具体的故障案例，一步步带你走完排查过程。有些案例是我自己踩过的坑，有些是帮客户排查的线上事故。希望能让你少走一些弯路。