要求线下面试？慎行！

分享一件组织内部成员遇到的趣事。

他前几天在 BOSS 上刷到个软件开发实习生的岗位，是家 0-20 人的小厂，写着招实习生，要求线下面试。想着多攒点面试经验也好，就抽时间过去了，结果一到地方就傻了眼。

哪是什么正经公司，分明是个套壳的。不仅业务跟 BOSS 上写的完全对不上，连公司名字都不一样。所谓的办公室，也就一个寝室那么大，挤得满满当当。

更离谱的是面试环节。全程没问一句技术问题，不管是数据库、框架这些硬知识，还是项目经历、八股文，提都没提。就绕着 “懂不懂软件开发流程”“会不会写文档” 这两个问题打转，剩下的时间全用来吹他们的业务多厉害。

所谓的业务，就是在网上接代写毕设的单子。50 块钱左右一份，还不包售后，全靠他们那所谓的 AI 工具一键生成，说三分钟就能出一个。招实习生进去，根本不用写代码，就是天天帮着做这些单子，早九晚七上班，每天还有做单指标。

所以在此提醒大家，线下面试需慎行，当然如果是中大厂肯定没啥问题，这种小厂一定要注意，别被坑了。

面经分享

下面分享一下来自上海的一个中小厂的后端面经，薪资是在20K左右，看看难度：

1. MongoDB能替代MySQL吗？

1. 可替代的场景

• 非结构化/半结构化数据：MongoDB的文档模型（JSON/BSON）支持动态模式，变更数据结构的场景（如用户行为日志、社交动态）。 • 高吞吐写入与扩展：原生分片和副本集设计，适合物联网传感器、实时日志等写入密集型场景。 • 敏捷开发需求：无需预定义表结构，加速迭代（如快速原型开发）。

2. 不可替代的场景

• 强事务与一致性：MySQL支持完整ACID事务（如金融交易、库存扣减），MongoDB仅支持有限的多文档事务。 • 复杂关联查询：MySQL擅长多表JOIN和复杂聚合，MongoDB需冗余数据或多次查询。 • 固定数据结构：如ERP、财务系统等需严格数据完整性的场景。

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

1. 工厂模式解决的问题

• 解耦对象的创建与使用：调用方无需依赖具体类，通过工厂接口获取对象，降低模块耦合度。 • 封装复杂创建逻辑：隐藏对象的初始化细节（如参数配置、依赖注入），简化调用代码。 • 提升扩展性：新增产品时无需修改已有代码，符合开闭原则（如新增日志类型只需扩展工厂类）。 • 支持动态配置：结合配置文件或依赖注入容器（如 Spring），实现对象类型的灵活切换。

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

抽象工厂是工厂模式的升级版，解决多产品族的统一创建问题： • 创建一组关联对象：例如 UI 系统中需要统一风格的按钮、输入框、弹窗等组件（如 Windows 或 Mac 风格）。 • 隔离产品族的实现：客户端仅依赖抽象接口，切换产品族只需更换工厂实例（如从工厂切换到 Mac 工厂）。

总结： • 工厂模式：核心是解耦对象创建与使用，适合单一产品的灵活生产。 • 抽象工厂：核心是统一管理产品族，确保关联对象的一致性（如跨平台兼容性）。 面试加分点：两者常结合使用，例如抽象工厂定义产品族，内部用工厂方法生产具体产品。

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 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、内存及网络带宽。 • 索引优化：为高频查询字段（如时间戳）创建索引，加速快照阶段扫描。

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. MySQL索引的类型及适用场景？B+树索引为什么适合范围查询？

1. MySQL索引类型及适用场景

• B+树索引（最常用）：

• 适用：主键查询、范围查询（如 WHERE age > 30）、排序（ORDER BY）、前缀匹配（如 name LIKE '张%'）。
• 不适用：全模糊匹配（name LIKE '%张%'）、非最左前缀的联合索引查询（如联合索引 (a,b) 查 b=5）。

• 哈希索引（Memory引擎为主）：

• 适用：精确匹配（如 WHERE id = 100），查询效率O(1)。
• 不适用：范围查询、排序，因哈希值无序。

• 全文索引：

• 适用：文本内容检索（如文章正文关键词搜索 MATCH(content) AGAINST('数据库')）。
• 不适用：短文本、非自然语言场景（效率低于B+树）。

• 空间索引：

• 适用：地理空间数据查询（如 WHERE ST_Distance(point, ...) < 1000）。

2. B+树索引适合范围查询的原因

• 有序性：B+树叶子节点按索引键值有序排列，且通过双向链表连接，范围查询时可直接遍历连续的叶子节点（如查 id BETWEEN 100 AND 200 只需定位起始点后顺序读取）。 • 聚簇索引特性：InnoDB中聚簇索引的叶子节点存储完整数据行，范围查询可直接获取数据，无需回表。 • 层级低：B+树为多路平衡树，层级通常3-4层（百万级数据），范围查询时定位起始点和结束点的IO次数少，效率高。

8. ClickHouse的MergeTree引擎原理？与MySQL的InnoDB引擎有何区别？

1. MergeTree引擎核心原理

ClickHouse的MergeTree是最核心的存储引擎，专为列式存储和高效分析设计： • 列式存储：数据按列而非行存储，查询时仅读取所需列，减少IO。 • 分区机制：按指定字段（如时间）自动分区，支持分区级别的TTL（数据过期自动删除）和并行查询。 • 排序与主键：每个分区内数据按主键排序，结合稀疏索引（mark文件）快速定位数据范围。 • 合并机制：写入数据先落盘为临时分区，后台异步合并小分区为大分区（类似LSM树），减少文件数并提升查询效率。 • 副本与分片：支持副本（ReplicatedMergeTree）保证高可用，分片实现水平扩展。

2. 与InnoDB引擎的核心区别