坐标上海，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 | MongoDB | ClickHouse |
|----------------|----------------------|----------------------|----------------------|
| 数据模型 | 结构化（表） | 半结构化（文档） | 列式存储 |
| 核心能力 | 事务、复杂查询 | 灵活模式、高扩展性 | 极速分析、实时聚合 |
| 写入性能 | 中等（支持实时） | 高（批量/实时） | 高（批量更优） |
| 查询场景 | 点查询、关联分析 | 文档检索、地理查询 | 聚合分析、范围查询 |
| 典型应用 | 订单系统、CMS | 游戏后端、IoT数据 | 广告分析、日志仓库 |

选型建议：
• 混合架构：用 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 的核心机制
   MongoDB CDC 通过 Change Stream API（3.6+版本支持）实时捕获数据变更（插入/更新/删除/替换），生成包含操作类型、文档ID、完整文档状态的变更流。支持断点续传（resumeToken）和全增量一体化读取（initial模式快照+增量）。
2. 与 Oplog 的对比
   • Oplog（旧方案）：复制日志记录操作，但仅包含部分更新字段，需二次查询补全数据，且分片集群处理复杂。
   • Change Stream 优势：屏蔽 Oplog 复杂性，提供完整文档状态、事件过滤、权限控制，简化开发。
3. Exactly-Once 语义
   通过 resumeToken 记录消费位置，故障恢复后从断点继续同步，结合 Checkpoint 机制保证数据不丢不重。

同步速度优化的核心手段

1. 并行化处理
   • 分片集群：从多个分片并行读取数据，通过采样分桶或按 ObjectID 范围切分任务。
   • Flink 并行度：增加 source.parallelism 参数，提升并发处理能力。
2. 批量与网络优化
   • 增大批量大小：调整 batch.size 减少网络 I/O 次数。
   • 心跳机制：启用 heartbeat.interval.ms 定期刷新 resumeToken，防止因无变更导致断点过期。
3. 硬件与配置调优
   • 资源升级：提升 MongoDB 集群的 CPU、内存及网络带宽。
   • 索引优化：为高频查询字段（如时间戳）创建索引，加速快照阶段扫描。

欢迎关注 ❤

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

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

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