# 流式缓存更新服务 面试问题清单  
*版本：2025-07-31*  

---

## 1. 项目速览（背景说明，不出题）

| 维度 | 简要回顾 |
|---|---|
| **项目目标** | 为广告服务器提供高并发数据缓存，支持实时广告投放决策。 |
| **整体架构** | 1. 数据摄入：Kafka 实时更新 + 周期性批量加载（MySQL）<br>2. 数据处理：Processor 引擎 + 子处理器 <br>3. 数据存储：Redis 高性能缓存<br>4. API 服务：Gin HTTP 接口（健康检查、指标、管理） |
| **核心模块** | • KafkaConsumerOperator：消费 Kafka 消息<br>• RepoManager：管理内存仓库，周期性同步 MySQL<br>• Processor：主处理引擎，分发任务<br>• 子处理器：处理特定数据类型（asset、section 等） |
| **技术栈** | • 语言：Go 1.20<br>• 数据库：Redis（缓存）、MySQL、DynamoDB、Neo4j<br>• 消息：Kafka<br>• 框架：Gin（Web）、Viper（配置）<br>• 序列化：Protobuf、FlatBuffers<br>• 搜索：Solr |

---

## 2. 深度技术面试题

> 以下问题按主题分组，题号连续，便于引用。

### 2.1 架构设计
**Q1.** 流式缓存更新服务 同时集成了 MySQL、DynamoDB、Neo4j 和 Solr。请解释为什么一个服务需要连接这么多不同类型的数据源？这种“异构数据源”架构（Polyglot Persistence）带来了哪些优势，同时又会引入哪些技术挑战或风险？  
**Q2.** `RepoManager` 在内存中维护了一个从 OLTP 数据库加载的数据仓库，而最终数据又会存入 Redis。请问 `RepoManager` 这个内存仓库和 Redis 缓存的角色和定位有何不同？为什么不能直接从数据源查询然后写入 Redis，而需要这个中间层？  
**Q3.** 请描述一下当一条 Kafka 消息（例如，一个 asset 更新消息）进入 流式缓存更新服务 后，从被消费到最终数据写入 Redis 的完整处理流程，并说明 `Processor` 在其中扮演的角色以及它与各个子处理器的交互方式。

### 2.2 技术选型
**Q4.** 项目选择 Redis 作为最终的业务缓存。与 Redis 或 Memcached 等其他缓存方案相比，您认为 Redis 在本项目（高并发广告服务）的场景下有哪些关键优势？  
**Q5.** 项目为什么选择 Go 语言作为主要的开发语言？请结合 流式缓存更新服务 作为一个高并发数据处理服务的特性来分析 Go 语言的优势（例如，并发模型、性能、内存管理等）。

### 2.3 性能优化
**Q6.** 在这个系统中，数据处理的延迟至关重要。请分析从 Kafka 消费消息到数据写入 Redis 的整个链路中，可能存在的性能瓶颈有哪些？你会如何定位和优化这些瓶颈？  
**Q7.** 项目代码中提到了 FlatBuffers 和 Protocol Buffers。为什么在这类高性能服务中倾向于使用这类序列化框架而不是 JSON？它们在性能和使用上有何具体差异？

### 2.4 数据一致性
**Q8.** 系统同时通过 Kafka 接收实时更新，并从 MySQL 进行批量加载。这种混合模式下，如何保证 Redis 缓存与上游数据源（特别是 MySQL）之间的数据最终一致性？请描述一个可能发生数据不一致的场景（例如，实时消息和批量加载同时操作同一份数据），并提出您的解决方案。

### 2.5 可扩展性
**Q9.** 假如未来的业务需求导致 Kafka 消息量或需要处理的数据实体类型增加一倍，你会如何扩展 流式缓存更新服务 以应对这种变化？请从服务实例、数据库连接、数据处理逻辑等多个角度阐述你的扩容策略。  
**Q10.** Kafka 在本架构中除了作为数据管道，还在可扩展性和系统韧性（Resilience）方面扮演了什么角色？如果 Kafka 集群出现故障，会对 流式缓存更新服务 产生什么影响？我们应该如何设计降级或恢复策略？

---

## 3. 行为与场景化面试题

> 以下问题按业务场景分组，题号连续，与上一部分衔接。

### 3.1 实时数据流处理与一致性
**Q11.**  
场景：在我们的系统中，一个来自 Kafka 的实时更新消息（例如，更新某个广告素材的状态）抵达了 `Processor`。但处理时发现，该素材的详细信息尚未从 MySQL 加载到内存仓库（`RepoManager`）中，或者内存中的数据版本较旧。  
问题：你会如何设计处理这条消息的策略？请详细阐述你的技术方案、决策理由以及不同方案的利弊（例如，是丢弃消息、将其放入延迟队列重试，还是先写入一个不完整的数据标记？）。

### 3.2 高并发查询与低延迟保障
（本组场景已融入 Q6、Q7 的性能优化讨论，无需重复出题。）

### 3.3 跨系统数据一致性保障
（本组场景已融入 Q8 的一致性讨论，无需重复出题。）

### 3.4 故障恢复与降级策略
**Q12.**  
场景：假设在一次广告投放高峰期，我们的一个核心依赖数据源 Neo4j 出现性能瓶颈，查询延迟从正常的 50 ms 飙升至 3 s。这直接导致 `Processor` 处理速度变慢，Kafka 出现大量消息积压，最终影响到广告数据的时效性。  
问题：作为负责人，你的应急响应步骤是什么？你会如何立即缓解问题？从长远来看，你会从架构层面提出哪些改进措施（例如，超时、熔断、缓存策略、异步化改造等）来增强系统对下游依赖不稳定的容错能力？

**Q13.**  
场景：在实现一个新功能时，你需要从一个新的业务团队维护的 DynamoDB 表中获取数据。但在联调过程中，你发现该表的设计无法满足你的查询性能要求，直接调用会导致 流式缓存更新服务 处理延迟增大。  
问题：你会如何处理这个情况？请描述你将如何准备数据和论据，以及如何与对方团队进行沟通，以推动他们对数据表结构或 API 进行调整？如果对方团队拒绝修改，你有什么备选方案（Plan B）来完成你的业务需求？

---

## 4. 使用说明（给面试官的提示）

| 候选人层级 | 建议选题 | 追问方向 |
|---|---|---|
| **初级/中级** | • 架构设计 Q1–Q3<br>• 技术选型 Q4–Q5<br>• 行为场景 Q11、Q13 | • 让候选人先画简版架构图，再深入细节。<br>• 追问“如果去掉 RepoManager 会怎样？”<br>• 关注沟通技巧与 Plan B 的可行性。 |
| **高级/资深** | • 性能优化 Q6–Q7<br>• 数据一致性 Q8<br>• 可扩展性 Q9–Q10<br>• 故障恢复 Q12 | • 要求给出可量化的性能指标（P99 延迟、QPS）。<br>• 让候选人设计监控与告警方案。<br>• 探讨多地域部署与双活架构。 |
| **专家/架构师** | • 全部题目 | • 要求评估整个系统的 CAP 取舍。<br>• 让候选人提出 6 个月到 1 年的演进路线图。<br>• 讨论成本优化与多云容灾策略。 |

> 面试官可根据现场时间灵活跳过某些题目，或把行为题作为技术题的延伸，以观察候选人在真实业务压力下的综合表现。