坐标上海，20K 的面试难度

新的一周，继续分享最新面经。

今天分享的依旧是组织内部朋友的面经，面试的岗位是上海的 Go\Java\Python 开发岗，薪资水平是 18~25K，可惜的是他本人在 mongodb 这一块答的不好，一面过后没有消息了。下面来看一下面试难度如何吧：

1. 自我介绍

2. 介绍项目

3. 为什么 MySQL、MongoDB、Clickhouse 都用，分别用在什么场景？

这里介绍一下三者的使用场景

1. MySQL（关系型数据库）

核心特点：

• 支持事务（ACID）、结构化数据存储、复杂查询优化

• 适用场景：

• 事务型系统：订单处理、用户管理、金融交易（强一致性需求）

• Web 应用：电商平台、CMS（如 WordPress）、社交媒体

• 企业级应用：ERP、CRM、财务系统（需复杂查询）

• 日志存储：结构化日志、审计记录（中等规模）

不适用：非结构化数据、PB 级数据分析、超高并发写入

2. MongoDB（文档型数据库）

核心特点：

• 灵活文档存储（JSON/）、动态模式、高扩展性

• 适用场景：

• 动态数据模型：游戏装备/状态、社交动态、实时日志（无需预定义结构）

• 高吞吐写入：物联网传感器数据、移动应用行为日志

• 地理位置查询：移动 App 定位服务、物流轨迹分析

• 内容管理：多格式文件存储（如图片、文本混合）

不适用：强事务需求（如金融交易）、复杂多表关联

3. ClickHouse（列式分析数据库）

核心特点：

• 列式存储、极致查询性能（PB 级）、实时分析

• 适用场景：

• 大数据分析：广告点击统计、用户行为实时报表（亚秒级响应）

• 日志/时序分析：系统监控、IoT 设备指标（高效聚合）

• BI 与数据仓库：复杂聚合查询、企业级决策支持

• 实时监控：服务器性能指标、广告投放效果追踪

不适用：高并发 OLTP 事务、频繁单行更新

对比总结

选型建议：

• 混合架构：用 MySQL 处理事务，ClickHouse 做分析，MongoDB 存动态数据。

• 性能取舍：需事务选 MySQL，需灵活模式选 MongoDB，需分析性能选 ClickHouse。

4. MongoDB 能替代 MySQL 吗？

1. 可替代的场景

• 非结构化/半结构化数据：MongoDB 的文档模型（JSON/BSON）支持动态模式，变更数据结构的场景（如用户行为日志、社交动态）。

• 高吞吐写入与扩展：原生分片和副本集设计，适合物联网传感器、实时日志等写入密集型场景。

• 敏捷开发需求：无需预定义表结构，加速迭代（如快速原型开发）。

2. 不可替代的场景

• 强事务与一致性：MySQL 支持完整 ACID 事务（如金融交易、库存扣减），MongoDB 仅支持有限的多文档事务。

• 复杂关联查询：MySQL 擅长多表 JOIN 和复杂聚合，MongoDB 需冗余数据或多次查询。

• 固定数据结构：如 ERP、财务系统等需严格数据完整性的场景。

5. ACID 了解吗，MySQL 是怎么实现事务的？读已提交怎么实现的？

1. ACID 特性

ACID 是数据库事务的四个核心特性，确保事务的可靠性和数据一致性：

• 原子性 (Atomicity) ：事务中的操作要么全部成功，要么全部失败（通过 undo log 回滚实现）。例如转账时，扣款和加款必须同时成功或回滚。

• 一致性 (Consistency) ：事务执行前后，数据库必须满足所有约束（如主键、外键），例如库存不能为负数。

• 隔离性 olation)：并发事务互不干扰，通过锁和 MVCC 实现。例如避免脏读、不可重复读等问题。

• 持久性 (Durability) ：事务提交后数据永久保存（通过 redo log 保证），即使宕机也能恢复。

2. MySQL 事务实现机制

MySQL 事务的实现依赖以下核心组件：

• Redo Log（重做日志） ：记录事务的物理修改，用于宕机后恢复已提交的数据，保证持久性。

• Undo Log（回滚日志） ：记录事务的旧版本数据，用于回滚未提交的事务，保证原子性。

• 锁机制：

• 行锁 ：写操作加锁，防止并发写冲突。

• Next-Key Lock（间隙锁） ：在可重复读级别下防止幻读。

• MVCC（多版本并发控制） ：通过版本链和 Read View 实现无锁读，支持高并发。

3. 读已提交（Read Committed）的实现原理

读已提交隔离级别通过 MVCC + 动态生成 Read View 实现：

• Read View 的生成时机：每次执行 SELECT 时都会生成新的 Read View，确保读取已提交的最新数据。

• Read View 的组成：

• creator_trx_id：当前事务 ID。

• m_ids：活跃事务 ID 列表。

• min_trx_id：活跃事务最小 ID。

• max_trx_id：下一个事务 ID（当前最大 ID +1）。

• 可见性判断规则：

1. 若数据版本的 trx_id < min_trx_id：可见（已提交）。

2. 若 trx_id > max_trx_id：不可见（未来事务）。

3. 若 trx_id 在 m_ids 中：（未提交事务）；否则可见（已提交事务）。

示例：事务 A 多次查询同一数据，若期间事务 B 提交了修改，事务 A 的后续查询会读取到新提交的数据，因为每次查询都会生成新的 Read View。

对比可重复读（Repeatable Read）

• 读已提交：每次查询生成新 Read View，可能读到其他事务提交的新数据（不可重复读）。

• 可重复读：事务首次查询生成 Read View 并复用，保证多次读取一致性（通过版本链和快照）。

6. MySQL 在事务提交后宕机如何保证数据恢复？

• Redo Log（重做日志）：事务提交前，所有修改操作先写入 Redo Log 并刷盘（物理日志），确保宕机后可通过重放日志恢复数据。

• Checkpoint 机制：定期将内存中的脏数据页刷盘，并记录最后一次刷盘的位置（LSN）。重启时只需恢复 Checkpoint 之后的日志，大幅缩短恢复时间。

• LSN（日志序列号）：全局唯一递增编号，标记数据页、日志、Checkpoint 的版本。恢复时对比数据页和 Redo Log 的 LSN，仅重放未落盘的修改。

• 两阶段提交：事务提交时分为 Prepare 和 Commit 阶段，确保 Redo Log 与 Binlog 的一致性。已 Commit 的日志必定重放，未 Commit 的日志回滚。

• 崩溃恢复流程：

1. 根据 Checkpoint 定位恢复起点；

2. 按 LSN 顺序重放 Redo Log（物理修改）；

3. 使用 Undo Log 回滚未提交事务。

7. 工厂模式解决了什么问题？抽象工厂？

1. 工厂模式解决的问题

• 解耦对象的创建与使用：调用方无需依赖具体类，通过工厂接口获取对象，降低模块耦合度。

• 封装复杂创建逻辑：隐藏对象的初始化细节（如参数配置、依赖注入），简化调用代码。

• 提升扩展性：新增产品时无需修改已有代码，符合开闭原则（如新增日志类型只需扩展工厂类）。

• 支持动态配置：结合配置文件或依赖注入容器（如 Spring），实现对象类型的灵活切换。

2. 抽象工厂模式解决的问题

抽象工厂是工厂模式的升级版，解决多产品族的统一创建问题：

• 创建一组关联对象：例如 UI 系统中需要统一风格的按钮、输入框、弹窗等组件（如 Windows 或 Mac 风格）。

• 隔离产品族的实现：客户端仅依赖抽象接口，切换产品族只需更换工厂实例（如从工厂切换到 Mac 工厂）。

总结：

• 工厂模式：核心是解耦对象创建与使用，适合单一产品的灵活生产。

• 抽象工厂：核心是统一管理产品族，确保关联对象的一致性（如跨平台兼容性）。

面试加分点：两者常结合使用，例如抽象工厂定义产品族，内部用工厂方法生产具体产品。

8. Mongodb CDC 原理讲一下？同步速度优化是什么意思？

1. 基于 Change Stream 的核心机制

2. MongoDB CDC 通过 Change Stream API（3.6+版本支持）实时捕获数据变更（插入/更新/删除/替换），生成包含操作类型、文档 ID、完整文档状态的变更流。支持断点续传（resumeToken）和全增量一体化读取（initial模式快照+增量）。

3. 与 Oplog 的对比

4. • Oplog（旧方案）：复制日志记录操作，但仅包含部分更新字段，需二次查询补全数据，且分片集群处理复杂。

5. • Change Stream 优势：屏蔽 Oplog 复杂性，提供完整文档状态、事件过滤、权限控制，简化开发。

6. Exactly-Once 语义

7. 通过 resumeToken 记录消费位置，故障恢复后从断点继续同步，结合 Checkpoint 机制保证数据不丢不重。

同步速度优化的核心手段

1. 并行化处理

2. • 分片集群：从多个分片并行读取数据，通过采样分桶或按 ObjectID 范围切分任务。

3. • Flink 并行度：增加 source.parallelism 参数，提升并发处理能力。

4. 批量与网络优化

5. • 增大批量大小：调整 batch.size 减少网络 I/O 次数。

6. • 心跳机制：启用 heartbeat.interval.ms 定期刷新 resumeToken，防止因无变更导致断点过期。

7. 硬件与配置调优

8. • 资源升级：提升 MongoDB 集群的 CPU、内存及网络带宽。

9. • 索引优化：为高频查询字段（如时间戳）创建索引，加速快照阶段扫描。

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：面试群。