1. Kafka
1.1 定位
分布式流数据平台，核心解决三大问题：
高吞吐的实时数据管道：支持每秒百万级消息处理。
持久化的消息队列：消息持久化到磁盘，支持多订阅者。
流式数据处理：与 Flink/Spark Streaming 集成，实现实时计算。
1.2 基础概念
| 组件 | 作用 |
|---|---|
| Producer | 消息生产者，将数据发布到指定 Topic（如日志采集器、应用事件埋点） |
| Broker | Kafka 服务节点，负责消息存储和转发。集群中多个 Broker 组成高可用架构 |
| Topic | 逻辑上的消息分类（如 order_events）。每个 Topic 分为多个 Partition 提高并行度 |
| Partition | 消息的物理分片，有序不可变序列，每条消息通过 Offset 唯一标识 |
| Consumer | 消息消费者，按需订阅 Topic（如实时计算任务、数据同步服务） |
| Consumer Group | 多个 Consumer 组成的组，共同消费一个 Topic，实现负载均衡（组内竞争 Partition） |
| Zookeeper/KRaft | 集群元数据管理与选举（Kafka 2.8+ 逐步移除 Zookeeper，改用 KRaft 协议） |
Broker（经纪人/服务节点）
可以理解为 "数据中转站" 或 "Kafka服务器"。
作用：Kafka集群中的一个工作节点，负责接收、存储和转发消息。多个Broker组成一个Kafka集群（类似快递公司的多个分拣中心）。
例子：假设Kafka是一个邮政系统，Broker就是各个城市的邮局。生产者把信件（消息）送到邮局，邮局负责暂存信件，并分发给对应的收件人（消费者）。
Topic（主题）
可以理解为 "消息分类" 或 "数据流名称"。
作用：逻辑上对消息进行分类，类似数据库中的"表"或文件系统中的"文件夹"。生产者向指定Topic发送消息，消费者订阅Topic获取消息。
例子：继续用邮政系统类比，Topic就是不同类型的邮件，比如：
订单通知 Topic：专门处理电商订单消息（如"您的订单已发货"）。
日志监控 Topic：专门传输服务器日志（如"用户A登录了系统"）。
Partition（分区）
可以理解为 "数据分片" 或 "并行处理的通道"。
作用：每个Topic可以分成多个Partition，实现数据的分布式存储和并行处理。消息在Partition内是有序的，但不同Partition之间无序。
例子：
假设订单通知 Topic有3个Partition，就像邮局的3个分拣窗口：
Partition 0：处理订单号以0结尾的订单（如订单100、订单200）。
Partition 1：处理订单号以1结尾的订单（如订单101、订单201）。
Partition 2：处理订单号以2结尾的订单（如订单102、订单202）。
发送消息 生产者 订单通知 Topic Partition 0 Partition 1 Partition 2 Broker 1 Broker 2 Broker 3 消费者组1 消费者组2 消费者组3
生产者（Producer）的数据是先发送到 Topic，但 Topic 的物理载体是 Broker。
- 指定Topic和Key 2. 路由到Partition 3. 存储在Broker Producer Topic Partition Broker
Offset 是 Kafka 中每条消息在 Partition 内的唯一位置标识（类似于数组下标）。例如，Partition 中的消息按顺序存储为Offset 0, 1, 2, ...。
作用：Consumer 通过记录已处理的 Offset，来标识消费进度。例如，若 Consumer 处理完 Offset 100 的消息，下一次会从 Offset 101 开始消费。
提交 Offset：Consumer 在处理完消息后，需显式或隐式地告知 Kafka："我已处理到 Offset X"。Kafka 会将此信息记录在内部 Topic __consumer_offsets 中。
1.3 数据流向
发布消息 存储消息 消费消息 提交Offset 集群协调 Producer Broker Topic/Partition Consumer __consumer_offsets Zookeeper/KRaft
1.4 性能调优
Producer：
批量发送（linger.ms 和 batch.size）。
压缩消息（compression.type=snappy）。
Consumer：
增加分区数提升并行度。
避免单 Consumer 处理过多 Partition（均衡负载）。
Broker：
调整 num.io.threads 和 num.network.threads 匹配硬件资源。
常见问题
消息积压：增加 Consumer 数量或优化处理逻辑。
数据倾斜：合理设计 Partition Key（避免热点 Key）。
重复消费：确保 Consumer 提交 Offset 的幂等性。
1.5 引申问题
Kafka 和 HDFS 都能存储数据，但本质不同：
Kafka 是流式数据的中转站，强调高吞吐、低延迟的实时传输，数据默认会滚动删除，适合作为消息队列或流处理管道；
HDFS 是批量数据的永久存储，针对大文件优化，支持复杂分析，适合离线计算。
例如，我们会用 Kafka 实时接收用户行为日志，再由 Flink 消费计算实时指标，同时定期将 Kafka 数据归档到 HDFS 供离线补算和审计。
2. Flink
2.1 定位
Apache Flink 是一个分布式流批一体计算引擎，设计目标是处理无界（流）和有界（批）数据，提供低延迟、高吞吐、精确一次（Exactly-Once）的计算能力。其核心特点是以流处理为原生模型，批处理被视为流处理的特殊情况。
2.2 组件
| 组件 | 角色 |
|---|---|
| JobManager | 集群的"大脑"，负责任务调度、Checkpoint协调、故障恢复。一个集群可有多个备用（HA） |
| TaskManager | 执行具体任务的节点，包含多个Task Slot（资源单元），负责数据计算与网络传输 |
| Resource Manager | 管理资源（如与YARN/K8s集成），分配TaskManager资源 |
2.3 计算流程
Flink 的执行模型可类比为 流式优化的 DAG（有向无环图），但更强调事件驱动的连续处理。以下是其核心阶段：
事件流 分区策略 数据源 转换操作: map/filter Shuffle 聚合/窗口操作: reduce/join 结果输出
阶段拆解
| 阶段 | 说明 |
|---|---|
| Source | 从外部系统（如 Kafka、文件）读取数据，生成 DataStream 或 DataSet |
| Transformation | 应用 map、filter、keyBy 等操作，构建处理逻辑链 |
| Shuffle | 根据 keyBy 或自定义分区器（Partitioner）重新分配数据（类似 MapReduce 的 Shuffle） |
| Window/Aggregate | 对 KeyedStream 应用窗口或聚合操作（如 reduce、sum、window） |
| Sink | 将结果写入外部存储（如数据库、Kafka） |