2. 技术选型与架构设计
做实时数据服务，说白了就是跟「快」字较劲。数据从产生到能被API消费，延迟要控制在秒级甚至毫秒级。这背后涉及消息队列、流计算引擎、状态存储三件套。选型选不好，后面全是坑。
我个人习惯，先定架构模式，再选具体组件。因为模式决定了数据流的走向，组件只是实现工具。你想想看，如果架构选错了，换组件也救不回来。
2.1 核心组件：Kafka、Flink、Redis 的角色
这三个东西，在实时数据服务里各司其职。我画了张图，你看一眼就明白了。
Kafka 是数据管道的心脏。所有原始数据先打到 Kafka，它负责削峰填谷。我在项目中遇到过，业务方直接往 API 里灌数据，QPS 瞬间冲到 5 万，如果没有 Kafka 挡在前面，Flink 和 Redis 早就被冲垮了。
Flink 是真正的计算引擎。它消费 Kafka 里的数据流，做窗口聚合、状态管理、复杂事件处理。嗯，这里要注意：Flink 的 Checkpoint 机制是保证 Exactly-Once 的关键，生产环境必须配好。
Redis 是状态存储和缓存层。Flink 算完的结果，写到 Redis 里，API 层直接从 Redis 读。毫秒级响应，全靠它。我曾经见过有人把计算结果写回 MySQL，结果 API 响应时间从 5ms 飙到 200ms，用户直接投诉。
2.2 架构模式：Lambda vs Kappa
聊完组件，咱们说说架构模式。这是实时数据服务设计的核心决策点。
2.2.1 Lambda 架构
Lambda 架构，说白了就是「两条腿走路」。一条是实时流处理，一条是离线批处理。两条路径各自算，最后在服务层合并结果。
| 特性 | 批处理层 | 流处理层 |
|---|---|---|
| 计算方式 | 定期全量计算 | 实时增量计算 |
| 延迟 | 分钟级到小时级 | 秒级 |
| 准确性 | 高（全量重算） | 中等（可能丢数据） |
| 存储 | HDFS / Hive | Kafka / Redis |
| 典型场景 | 日报、月报、历史回溯 | 实时大屏、实时告警 |
Lambda 架构的好处是准确。批处理层可以全量重算，纠正流处理层的偏差。但坏处也很明显——维护两套代码，两套计算逻辑。我在项目中遇到过，批处理和流处理算出来的结果对不上，排查了三天，最后发现是窗口边界定义不一致。
2.2.2 Kappa 架构
Kappa 架构就简单多了。只有一条流处理链路，所有数据都走实时流。如果需要重算，就重新消费 Kafka 里的历史数据，再跑一遍流作业。
你想想看，Kappa 架构的核心假设是什么？是 Kafka 能保存足够长的历史数据。如果 Kafka 只保留 7 天，那你想重算一个月前的数据，就没办法了。
2.3 如何选择：决策框架
选 Lambda 还是 Kappa？我总结了一个决策框架，你照着走就行。
决策点其实就三个：
- 历史重算需求：业务是否需要回溯 30 天以上的数据？如果需要，Lambda 更合适。如果不需要，Kappa 更简单。
- 团队维护能力：你们团队能同时维护两套代码吗？我见过一个 5 人小团队硬上 Lambda，结果批处理和流处理各写各的，半年后代码完全对不上。
- Kafka 存储容量：Kafka 集群能保存多久的数据？如果只能保存 7 天，Kappa 的重算能力就受限了。
2.4 技术栈组合推荐
最后，我给出几套经过实战验证的组合方案。你根据团队规模和业务场景对号入座。
| 方案 | 适用场景 | 技术栈 | 维护成本 |
|---|---|---|---|
| 轻量级 | 小团队，简单实时计算 | Kafka + Flink + Redis | 低 |
| 标准级 | 中型团队，需要历史回溯 | Kafka + Flink + Redis + HDFS | 中 |
| 企业级 | 大型团队，高可用高吞吐 | Kafka + Flink + Redis + HDFS + Druid | 高 |
轻量级方案适合大多数场景。Kafka 做缓冲，Flink 做计算，Redis 做存储，三件套搞定。标准级方案加了个 HDFS，用于批处理层的全量计算。企业级方案再加 Druid，用于 OLAP 查询。
嗯，这里要注意：不要一开始就上企业级方案。我见过太多团队，项目还没上线，先搭了一套 Hadoop 集群，结果半年过去了，数据量连 100GB 都不到，纯属浪费。