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

新的一周，继续分享最新面经。 今天分享的依旧是[组织内部](https://mp.weixin.qq.com/s/OQD8MJakqkgMxdyvaYoX7w)朋友的面经，面试的岗位是**上海的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**，备注：面试群。