上海钛松科技后端面经：MySQL 与 MongoDB、InnoDB 日志与 RBAC

《面试题目》

项目演示与准备

1. 为什么项目中同时使用 MongoDB 与 MySQL？

数据库与底层数据结构

2. MySQL 与 MongoDB 的核心差异是什么？
3. 什么是关系型数据库？
4. MySQL InnoDB 引擎为什么普及 / 有什么优势？
5. InnoDB 崩溃恢复日志有哪些？
6. HashMap 底层原理是什么？
7. 链表的基础定义是什么？

AI Agent 项目与技术架构

8. 项目中是否涉及知识库？
9. AI Agent 的具体架构是什么？
10. 底层模型是否自行购买了 GPT 相关模型？

Java 基础与权限框架

11. AOP 与 IOC 的核心区别是什么？
12. AOP 的实际业务场景有哪些？
13. 系统通用的权限模型（如 RBAC）及库表设计了解吗？
14. 是否使用过 Spring Security 框架？具体机制是什么？

《参考解析》

为什么 MySQL + MongoDB 并存：MySQL 承担强一致、需要事务和复杂查询的核心业务数据（用户、订单、答题结果、权限），MongoDB 承担半结构化、写多读多、结构易变的数据（会话消息、面试快照、工具调用记录）。这样分工的理由是：消息和快照字段不固定、单条文档可能很大，用 MySQL 拆表会很别扭；而核心交易数据需要事务、外键、聚合查询，MongoDB 不擅长。代价是跨源一致性，要用「以 MySQL 为准 + 异步快照 + 幂等重放」来兜。

MySQL 与 MongoDB 的核心差异：MySQL 是关系型，数据以行和列组织，强 schema、支持 ACID 事务、SQL 查询、join 与二级索引，适合结构化与强一致场景；MongoDB 是文档型，数据以 BSON 文档组织，schema 灵活、支持嵌套与数组、水平分片容易，事务能力较弱（4.0 起支持多文档事务但有性能代价），适合半结构化、快速迭代、读多写多的场景。选型看「数据结构是否稳定、是否需要事务、查询模式是否可预知」。

关系型数据库：以关系模型（表、行、列）组织数据，用主键/外键表达实体关系，支持 SQL、事务（ACID）、约束与规范化设计。核心价值是「数据独立性 + 强一致 + 声明式查询」，让应用不用关心物理存储与访问路径。

InnoDB 为什么普及：支持事务（ACID）、行级锁与 MVCC（并发读写不互相阻塞）、崩溃恢复（redo/undo）、外键、聚簇索引（主键即数据组织方式，主键查询快）、缓冲池与自适应哈希等优化；它是 MySQL 5.5 之后的默认引擎，生态与工具支持最完整。相比 MyISAM，InnoDB 的行锁和事务是生产环境的刚需。

崩溃恢复日志：核心是 redo log 和 undo log。redo log 是物理日志，记录「哪个页做了什么修改」，采用 WAL：事务提交先写 redo（innodb_flush_log_at_trx_commit 控制刷盘），崩溃后用 redo 重放已提交但未落盘的数据；undo log 是逻辑日志，记录反向操作，用于事务回滚和 MVCC 的版本链。还有 binlog（Server 层，逻辑日志，用于主从复制与归档）、relay log（从库）、以及 doublewrite buffer（防止页断裂，保证页写入原子性）。回答时把「redo 保证持久性、undo 保证原子性、binlog 保证复制」这条线讲清。

HashMap 底层：JDK 1.8 是数组 + 链表 + 红黑树。hash(key) 做扰动（高 16 位异或低 16 位）后与 n-1 做与运算定位桶；空桶直接放，冲突挂链表，链表长度到 8 且数组长度到 64 转红黑树，低于 6 退化回链表；负载因子 0.75，超过阈值扩容为两倍，扩容时元素要么留在原位置、要么移到「原位置 + 旧容量」。1.7 是数组 + 链表，头插法，扩容可能形成环；1.8 改尾插避免成环。线程不安全，并发场景用 ConcurrentHashMap。

链表：由一系列节点组成，每个节点存数据和指向下一个节点的指针，逻辑上连续、物理上可以不连续；优点是插入删除 O(1)（已知前驱）、动态扩容方便，缺点是不能随机访问、查找 O(n)、有额外指针开销。常见变体有双向链表、循环链表、带头节点链表；工程里常和哈希表组合（LinkedHashMap、LRU）或用于队列。

知识库与 Agent 架构：知识库通常分「文档接入 → 解析清洗 → 切分 → 向量化 → 存储（向量库 + 元数据）→ 检索（向量 + 关键词混合）→ 重排 → 注入上下文」。Agent 架构分四层：接入层（会话、鉴权、限流）、编排层（规划、路由、工具调用循环）、能力层（模型、检索、工具、记忆）、基础设施层（模型网关、向量库、日志与评测）。回答时落到你项目里具体用了什么、为什么。

模型是否自购：如实回答。常见做法是通过云厂商 API 或聚合网关调用，按 token 计费；自购指私有化部署或包年订阅。可以补一句成本控制：按任务选模型、缓存相同请求、限制最大输出、监控 token 消耗。

AOP 与 IOC：IOC 是控制反转，对象的创建与依赖装配交给容器，目的是解耦与可测试；AOP 是面向切面，把横切关注点（日志、事务、权限、缓存、监控）从业务代码里抽出来，通过代理在方法前后织入。两者解决的问题不同：IOC 管「对象怎么来」，AOP 管「公共逻辑怎么复用」；实现上都依赖 Spring 的 Bean 容器与代理机制。

AOP 的业务场景：声明式事务（@Transactional）、统一日志与链路追踪、权限校验、接口限流与幂等、缓存注解、审计、异常统一处理、性能监控。要注意代理失效的场景：同类内部方法调用、private 方法、final 类，因为这些不经过代理。

RBAC 与表设计：RBAC 是「用户 → 角色 → 权限」的模型。基础表：user、role、permission（或 menu/resource）、user_role、role_permission；权限可以细化到「资源 + 操作」（如 order:read），支持角色继承与数据权限（部门、本人、全部）。设计要点是权限码稳定、角色可组合、鉴权在服务端做，前端只做展示控制。

Spring Security 机制：基于过滤器链（SecurityFilterChain），请求先经过一系列过滤器完成认证（用户名密码、JWT、OAuth2）、会话或 token 解析、异常处理，再由 AuthenticationManager 调用 UserDetailsService 加载用户与权限，认证成功后把 Authentication 放入 SecurityContext；授权通过 @PreAuthorize、HttpSecurity.authorizeHttpRequests 或自定义 AccessDecisionManager 完成。JWT 场景通常是无状态：登录签发 token，过滤器解析并校验签名与过期时间，再把权限放进上下文。