第4章 实时计算核心组件（Kafka、Flink、HBase）
本章聚焦三大组件的高频面试题，覆盖原理、实践、对比与公司侧重点。大厂（字节、阿里、腾讯）常考察高可用/一致性/性能调优；中小厂更关注成本/易用性/常见问题排查。以下回答框架和模板可灵活迁移。
面试题1：如何保证Kafka消息不丢失？
考察点：
- 是否理解Producer/Consumer/Sync异步机制
- ACK参数、ack=-1、ISR、min.insync.replicas
- 消费端offset提交方式及幂等性
回答框架：场景定位（数据准确性要求）→ 原理（分区副本、ACK、Leader/Epoch）→ 实践（Producer ack=-1、重试；Consumer手动提交+幂等）→ 对比（与其他MQ的可靠性差异）→ 总结（权衡性能与可靠性）。
示例回答：Kafka消息不丢失需从三端入手：Producer 设置 ack=-1 并开启 retries；Topic 参数 replication.factor≥3、min.insync.replicas=2；Consumer 采用手动异步提交 offset，配合 Kafka 幂等性实现精确一次语义。同时注意 Broker 端 unclean.leader.election 设为 false 避免数据不一致。
可能追问：
- acks=-1 与 all 的区别？
- 如果ISR只剩一个副本怎么处理？
- 事务和幂等性能开销如何？
面试题2：Flink Checkpoint 机制原理与调优？
考察点：
- Barrier 对齐、分布式快照算法
- Checkpoint 与 Savepoint 区别
- Checkpoint 失败导致重启的策略
回答框架：场景（故障恢复需求）→ 原理（Chandy-Lamport、Barrier、State Backend）→ 实践（Checkpoint 间隔、最小/超时时间、并发数）→ 对比（与 Spark Streaming 的 micro-batch 恢复机制）→ 总结（保证 exactly-once 的代价）。
示例回答：Flink Checkpoint 基于分布式快照：JobManager 下发 Barrier 到 Source，各算子对齐 Barrier 后异步快照状态到 State Backend。调优时设置 checkpoint interval 30s、min-pause 10s，同时使用增量 Checkpoint 减少存储压力。失败时根据策略可重启 Job 并从最近完成点恢复。
可能追问：
- 非对齐 Checkpoint 与对齐的区别？
- State Backend 选择 RocksDB vs Heap？
- Checkpoint 过大导致 OOM 怎么处理？
面试题3：HBase RowKey 设计原则及热点问题解决？
考察点：
- RowKey 散列性、Region 拆分的影响
- 预分区与 Salt/Reverse 等方式
- 读/写热点场景的应对
回答框架：场景（实时 OLTP 查询）→ 原理（RowKey 字典序存储、Region 分裂策略）→ 实践（加盐、哈希反转、支持多维度查询）→ 对比（与 Cassandra 分区键设计）→ 总结（平衡扫描效率与写负载）。
示例回答：RowKey 设计核心是避免写热点：采用哈希前缀或反转前缀实现均匀分布，例如“userid_hash(4) + timestamp 反转”。预分区数量为 RegionServer 数×2~3，同时使用分隔符保留扫描前缀能力。针对读热点可通过二级索引（Phoenix）或 Bloom Filter 优化。
可能追问：
- Region 自动拆分与手动预分区哪个好？
- 高吞吐写入时如何防止 Region Server 频繁分裂？
- 如何设计支持按时间范围扫描？
📁 项目案例：实时数仓分钟级延迟指标系统
| 项目名称 | 实时数仓分钟级延迟指标系统 |
|---|---|
| 业务背景 | 电商大促期间，业务需要实时查看店铺流量、转化、GMV等指标，支持秒级维度下钻（按城市、商品、渠道）。 |
| 规模指标 | 数据量：每日 5 亿条事件，峰值 QPS 5k；窗口计算：1分钟、5分钟滑动窗口；状态大小：每天约 200GB。 |
| 技术栈 | Kafka（消息队列）、Flink（计算引擎）、HBase（实时维表/结果表）、Redis（缓存热数据）、HDFS（冷数据归档） |
| 核心难点 |
|
| 面试高频追问 |
|
| 可迁移回答话术 | “在峰值写入场景下，我们优先保证写入线性扩展性，采用哈希前缀 + 预分区避免 Region 热点；Flink 使用 RocksDB 减少 Heap 压力，并开启增量 Checkpoint 缩短快照时间；对于 HBase 维表，使用负载均衡的客户端批量写入，配合 setWriteBufferSize 降低 RPC。” 这段描述可迁移到任何需要高吞吐实时写入的系统。 |