2. 流数据基础：流数据的概念、与批处理的区别、金融流数据的典型特征

好，咱们进入正题。这一节聊的是流数据的基础。说实话，很多做金融系统的朋友，一开始都容易把流数据和批处理搞混。我当年刚入行时也踩过这个坑——以为只要数据能跑起来就行，结果线上出了大问题。

流数据，说白了就是数据在产生的同时就被处理。它不是等数据攒够了再统一算，而是来一条处理一条。你想想看，股票行情每秒成千上万笔，等攒够了再算？黄花菜都凉了。

2.1 流数据的概念

流数据是一种无界数据。什么叫无界？就是数据一直在产生，没有终点。比如交易所的实时行情、用户点击日志、传感器数据，这些都是流数据。

它的核心特征有三个：

• 持续到达：数据源源不断，不会停
• 顺序重要：数据到达的顺序往往决定了业务逻辑
• 不可重放：错过就错过了，除非你专门做了持久化

我个人习惯把流数据想象成一条传送带。零件（数据）一个接一个过来，工人（处理逻辑）在传送带旁边直接干活。你不能等传送带停了再干，因为传送带永远不会停。

2.2 流数据与批处理的区别

这个区别，我建议你从三个维度来理解：

举个例子你就明白了。批处理就像期末考试阅卷——等所有卷子收齐了，统一批改。流处理呢，就像课堂提问——学生回答一个，老师点评一个。你说哪个更适合实时风控？显然是后者。

我在项目中遇到过这样一个场景：某支付系统原本用批处理做交易对账，每天凌晨跑一次。结果有一次白天出了个重复支付的问题，等到第二天才发现，用户都投诉到监管那里去了。后来改成流处理，每笔交易实时校验，问题秒级发现。

2.3 金融流数据的典型特征

金融领域的流数据，跟普通流数据不太一样。它有三大硬性要求：

2.3.1 高吞吐

金融系统的吞吐量，我见过最夸张的是某头部券商的核心交易系统，峰值每秒处理超过 50 万笔行情。你想想看，这相当于每秒要处理 50 万次数据到达、解析、校验、分发。一般的消息队列根本扛不住。

高吞吐带来的挑战是什么？背压。当生产者速度远大于消费者速度时，系统会崩溃。我曾经见过一个系统，因为行情暴涨，Kafka 消费者处理不过来，结果消息积压到磁盘爆满，整个集群挂了。

2.3.2 低延迟

金融交易对延迟的要求，可以用「变态」来形容。交易所的行情从产生到送达交易员，延迟要求通常在 10 毫秒以内。高频交易更是追求微秒级。

低延迟意味着什么？

• 不能做复杂的计算（比如机器学习推理）
• 网络传输要优化（比如用 RDMA 替代 TCP）
• 序列化要轻量（比如用 Protobuf 替代 JSON）

我建议你在设计流处理系统时，把延迟预算分配好。比如总延迟要求 10ms，那网络传输占 2ms，序列化占 1ms，业务逻辑占 5ms，剩下的 2ms 留给 GC 和调度。这样你才知道瓶颈在哪。

2.3.3 有序性

这个最容易被忽视，但也是最要命的。金融数据对顺序极其敏感。比如：

• 先有「买入委托」，后有「成交回报」——顺序乱了，成交回报先到，系统会认为这是一笔非法交易
• 先有「撤单指令」，后有「成交确认」——如果顺序颠倒，撤单还没生效，成交却先来了，系统会多出一笔持仓

为什么会这样？因为金融业务是状态驱动的。每个事件都会改变系统状态，而状态的变更必须严格按照时间顺序。一旦乱序，状态就乱了，账就算不清了。

2.4 知识体系总览

下面这张图，是我自己总结的金融流数据知识体系。你可以把它当作本章的思维导图：

嗯，这张图把三个特征的关系说清楚了。高吞吐、低延迟、有序性，三者不是独立的，而是相互制约的。比如你为了保有序性，可能要多加一个排序步骤，延迟就上去了。你为了提吞吐，可能要用批量处理，但有序性又难保证了。

所以实际设计时，你得根据业务场景做取舍。比如：

• 行情推送：高吞吐 + 低延迟优先，有序性可以适当放宽（丢几条行情影响不大）
• 交易流水：有序性必须保证，延迟可以稍微牺牲一点
• 风控系统：三者都要硬，但可以通过架构设计来平衡

好了，这一节就到这里。流数据的基础概念和金融特征，你心里应该有数了。下一节我们会深入聊一致性模型——那才是真正烧脑的地方。

公众号:蓝海资料掘金营，微信deep3321