面经复盘：某 SaaS 中厂业务后端中级岗（3–5 年）一二面：数据一致性、报表批处理、多租户与线上排查

先声明：本文是“根据公开面经整理与改编”的一场典型面试，不是我本人的亲历，也不指向任何具体公司或面试官。我读了近一年公开的后端面经、多租户与高并发方向的技术文章，把 SaaS 或中厂业务后端岗位里反复出现的题目和追问串成了两轮面试。问答是拼的，题目是真的，回答思路是我的点评。

SaaS/中厂的中级岗（3–5 年）和大厂高级岗有个明显区别：他们不太关心你能不能设计一个百万 QPS 的系统，更关心你能不能把一个“业务复杂、数据敏感、客户会投诉”的系统做稳。客户是企业，数据错一分钱、报表慢一分钟、一个租户的操作拖垮所有人，都是事故。所以面试的重心是：数据一致性、多租户隔离、报表与批处理、线上问题排查、项目里你到底做了什么。八股会问，但多半是奔着“你在业务里怎么用”去的。

一、面试流程总览

这类公司常见流程：一面（技术，约 60 分钟，偏基础加业务场景）、二面（技术负责人，约 60 分钟，偏项目深挖与排查）、HR 面（约 30 分钟）。有的会在一面前加一轮笔试或在线编程。下图是这场“典型面试”的时间线。

二、一面：基础 + 业务场景（约 60 分钟）

考察目标：确认你的基础足够支撑业务开发，同时用几道“带业务味”的场景题看你的思维方式。中级岗一面通常 40% 基础、60% 场景。

Q1：自我介绍，然后说说你目前负责的业务和你的角色

参考回答要点：“3–5 年，做过 XX 类业务系统，目前负责某个模块（比如计费、订单、报表、权限）。”重点是把业务讲成技术人能听懂的样子：这个模块的输入输出是什么、数据量多大、最容易出问题的点是什么。

追问：“这个模块每天数据量多少？高峰在什么时候？”——SaaS 常见的高峰是月初/月末（对账、结算、报表）、整点定时任务、大客户批量导入。能说出你业务的“峰值形状”就已经超过一半的中级候选人。

踩坑：只讲“我用了 Spring Boot + MyBatis 做增删改查”，没有任何业务约束和难点，面试官会认为你还停留在初级。

Q2：Spring 事务什么情况下会失效？

参考回答要点：Spring 声明式事务基于 AOP 代理，常见失效场景：

• 同一个类内部方法调用（this.xxx()），没有经过代理对象；
• 方法不是 public（基于 CGLIB/JDK 代理的默认限制，Spring 6 对 protected/包可见有一定放宽，不确定时说明版本）；
• 异常被 catch 吞掉，或抛出的是受检异常而没有配置 rollbackFor（默认只对 RuntimeException 和 Error 回滚）；
• 数据库引擎不支持事务（MyISAM）；
• 多线程里开新线程，事务上下文（ThreadLocal）不传递；
• 传播行为配置不当，如 REQUIRES_NEW 让内层事务独立提交，外层回滚时它已提交。

追问：“事务里调用了 RPC 或发了 MQ，会有什么问题？”——数据库回滚了，消息却发出去了（或者反过来）。这是通向“事务消息/本地消息表”的门，答好了后面就顺了。

加分：提到 TransactionSynchronizationManager.registerSynchronization 或 @TransactionalEventListener(phase = AFTER_COMMIT)，保证“提交之后才发消息”，但要清楚它仍不解决“提交成功但发消息失败”的问题，需要本地消息表兜底。

Q3：怎么保证“订单创建成功 + 通知下游”的数据一致性？

参考回答要点：业务里最实用的是本地消息表（Outbox）：在同一个本地事务里写业务表和消息表；由独立的投递任务扫描消息表发 MQ，发送成功后标记完成；消费端做幂等。这样把“跨系统一致性”降级成“本地事务 + 至少一次投递 + 幂等消费”。

@Transactional
public void createOrder(OrderCmd cmd) {
    orderMapper.insert(order);
    outboxMapper.insert(new Outbox("ORDER_CREATED", order.getId(), payloadJson, "NEW"));
}

// 独立定时/常驻任务
public void deliver() {
    List<Outbox> list = outboxMapper.selectPending(200);
    for (Outbox o : list) {
        try {
            mq.send(o.getTopic(), o.getPayload());
            outboxMapper.markSent(o.getId());
        } catch (Exception e) {
            outboxMapper.incrRetry(o.getId()); // 超过阈值告警
        }
    }
}

追问：“消息表怎么清理？”——定期归档已发送记录；“投递任务多实例会重复投递吗？”——会，所以消费端必须幂等，或者用分片/行锁（select … for update skip locked，MySQL 8.0 支持）领取任务。“为什么不用 Seata/TCC？”——SaaS 场景里大多数跨服务操作可接受最终一致，TCC 侵入性强、要处理空回滚/悬挂，成本高，除非涉及钱且必须强一致。

踩坑：只回答“用分布式事务框架”，说不出代价；或者只说“MQ 重试”，忽略消息可能压根没发出去。

Q4：接口幂等怎么做？

参考回答要点：幂等 = 同一请求执行一次和执行多次结果一致。常用手段：

1. 数据库唯一索引（业务唯一键，如“租户 + 外部单号”），最可靠的兜底；
2. 幂等表/去重表：请求带幂等 key，先插入去重表，成功才执行；
3. 状态机 + 条件更新：update … set status='PAID' where id=? and status='UNPAID'，影响行数为 0 就说明已处理；
4. Token 机制：先取 token，提交时原子校验并删除（Redis Lua），适合防表单重复提交。

追问：“幂等 key 由谁生成？”——由调用方生成并保证同一业务动作用同一个；“幂等记录保存多久？”——覆盖最长重试窗口即可，比如几天到几周；“先查后插有并发问题吗？”——有，必须靠唯一索引兜底，而不是 select 再 insert。

Q5：多租户系统的数据隔离有哪几种方案？你们用哪种？

参考回答要点：公开资料里最常见的三种：

实践上常见分域混合：中小客户走共享表，大客户或合规要求高的走独立库，通过“租户路由表”决定数据源。多数团队建议从共享表起步，但预留切换空间（所有访问都经过统一的租户上下文和数据源路由）。

追问链：

• “共享表怎么保证每条 SQL 都带 tenant_id？”——不靠人肉，靠框架：MyBatis-Plus 的 TenantLineInnerInterceptor 之类的 SQL 拦截器自动追加条件；ORM 层用全局过滤；数据库层可考虑行级安全（PostgreSQL RLS 这类能力，MySQL 没有原生 RLS）。
• “租户 ID 从哪来？”——登录态/JWT 解析后放入 ThreadLocal 的租户上下文，网关或拦截器统一设置；异步线程、定时任务、MQ 消费者里租户上下文会丢，必须显式传递和恢复。
• “联合索引怎么设计？”——tenant_id 通常放在最左，因为几乎所有查询都带它；但要评估租户间数据倾斜。
• “一个大租户把库压垮怎么办？”——限流与配额（按租户的 QPS/并发/导出次数）、线程池隔离、大租户迁到独立库。

踩坑：只会说“加 tenant_id”，被问到“定时任务/MQ 里怎么办”“跨租户统计怎么做”就哑火；或者把 Redis key 忘了加租户前缀，造成缓存串数据——这是真实高频事故。

Q6：MySQL 深分页怎么优化？（报表/导出常见）

参考回答要点：limit 1000000, 20 会扫描并丢弃前 100 万行。优化：

1. 游标/键集分页：where id > :lastId order by id limit 20，适合“下一页”类场景；
2. 延迟关联：先在覆盖索引上取出 id，再回表：select t.* from t join (select id from t where … order by id limit 1000000,20) x on t.id=x.id；
3. 限制最大翻页深度，或改成条件筛选 + 导出任务。

追问：“游标分页能跳页吗？”——不能，产品上要权衡；“排序字段不唯一怎么办？”——用（排序字段, id）组合做游标。

Q7：Redis 在你的业务里怎么用？有踩过坑吗？

参考回答要点：缓存（配置、字典、租户信息）、分布式锁（防重复提交、定时任务互斥）、计数与限流、幂等 token。坑：大 key（一个 Hash 上百万 field）导致阻塞、批量 KEYS *、过期时间集中导致雪崩、缓存与库不一致、多租户 key 无前缀。

追问：“定时任务多实例部署，怎么保证只有一个执行？”——分布式锁（带过期与续期）或调度平台的分片/单点执行；但要让任务本身幂等，因为锁过期后仍可能重复执行。

Q8：一道 SQL 题：查询每个租户本月订单金额前 3 的客户

select tenant_id, customer_id, total
from (
  select tenant_id, customer_id, sum(amount) as total,
         row_number() over (partition by tenant_id order by sum(amount) desc) rn
  from orders
  where created_at >= '2026-09-01' and created_at < '2026-10-01'
  group by tenant_id, customer_id
) t
where rn <= 3;

窗口函数在 MySQL 8.0 才支持；如果公司还在 5.7，要能用变量或自连接写。追问：“数据量大了这条 SQL 怎么优化？”——按时间范围走索引（tenant_id, created_at）、预聚合汇总表、放到只读从库或分析库，不要在主库跑大聚合。

三、二面：项目深挖 + 报表批处理 + 线上排查（约 60 分钟）

考察目标：技术负责人在看你的“工程判断力”：遇到需求你怎么拆、遇到故障你怎么查、遇到性能问题你怎么权衡。这一轮基本都是开放题。

Q9：讲一个你做过的报表功能：数据量、怎么算、慢了怎么办

参考回答要点：报表慢的根源通常是“在线业务库上做实时大聚合”。分层方案：

1. 明确实时性要求：多数报表 T+1 或分钟级延迟即可，不必实时；
2. 预聚合：按天/租户维度的汇总表，由定时任务或流式增量更新；查询只读汇总表；
3. 读写分离/分析库：报表查从库或同步到分析型存储（如 ClickHouse/Doris 一类），避免影响主库；
4. 缓存：热门报表结果缓存，带租户与条件维度的 key；
5. 大数据量导出异步化：提交任务 → 后台分页/游标读取 → 流式写文件 → 通知下载，限制并发和每租户导出频率。

追问：“汇总表和明细数据对不上怎么办？”——对账任务（汇总 vs 明细重算）+ 支持按天重算的幂等任务；“导出 100 万行内存爆了？”——不要一次 selectList，用游标/流式查询（MyBatis 的 Cursor 或 JDBC fetchSize）+ 流式写入（如 EasyExcel 的方式），边读边写；“客户要自定义报表怎么办？”——限制可选维度和时间跨度，必要时提供异步生成而不是自由 SQL。

踩坑：只说“加索引”“加缓存”，没提“预聚合”和“读写分离”；或者不谈实时性，默认所有报表都要实时。

Q10：月底对账/结算这种大批量处理，你怎么设计批处理任务？

参考回答要点：批处理设计的关键词：分片、幂等、断点续跑、限速、可观测。

• 分片：按租户或主键范围切成小批次并行处理，每批控制事务大小（几百到几千条），避免大事务；
• 幂等：每个批次有唯一 ID 与状态（待处理/处理中/成功/失败），重跑不会重复入账；
• 断点续跑：失败只重试失败批次；记录进度游标；
• 限速与隔离：批处理与在线流量抢资源，要限制并发、错峰、使用独立线程池甚至独立实例，读走从库；
• 可观测：进度、耗时、失败数、告警；跑不完要有人知道。

如果用 Spring Batch，可以聊 chunk 处理（reader → processor → writer，按 chunk 提交事务）、JobRepository 保存执行状态、失败重启、skip/retry 策略。

追问：“批处理跑到一半服务重启了？”——靠批次状态表恢复，处理中状态设超时回收；“怎么保证多实例不重复处理同一批？”——领取时用条件更新（update … set status='RUNNING', owner=? where id=? and status='NEW'），影响行数为 1 才算抢到；“大租户和小租户混跑，大租户拖慢整体？”——按租户规模分队列，或者给每租户设并发上限。

Q11：线上出现“某个租户反馈系统很慢，其他租户正常”，怎么排查？

这是多租户系统里非常“味”的题。回答思路：先缩小范围，再找差异。

1. 确认现象：是某个接口还是全部？何时开始？有没有最近发布/配置变更？
2. 用租户维度筛选监控与日志（这要求日志和指标本来就带 tenant_id，这是平时要做好的基建）；
3. 对比该租户与正常租户的差异：数据量（是否是超大租户）、调用模式（是否在做批量导入/导出）、功能开关或定制配置；
4. 查慢 SQL：该租户的数据分布导致执行计划走偏（统计信息不准、索引选择性差）；
5. 查资源争用：是否占满共享线程池/连接池，影响他人（或反过来被别人影响）。

处置：短期给该租户限流或错峰、优化 SQL/加索引、必要时手工更新统计信息（ANALYZE TABLE）；长期做租户级配额与隔离，超大租户迁独立库。

加分：主动说“我们在日志、trace、指标里都埋了租户维度，否则这种问题只能靠猜”。

Q12：线上 CPU 飙高/接口变慢，你的排查套路？

参考回答要点：CPU 高：top 找进程 → top -Hp PID 找线程 → printf '%x' TID 转十六进制 → jstack PID | grep -A 20 nid=0x… 看栈；如果线程是 GC 线程则转去分析 GC。接口变慢：监控 → 链路追踪 → 慢 SQL → 下游 → 线程池/连接池 → GC。要强调先保留现场再重启（dump 线程栈、堆快照），重启前至少抓 2–3 份线程栈对比。

追问：“如果是正则导致的 CPU 100%？”——灾难性回溯（嵌套量词如 (a+)+），修法：简化正则、用原子分组/占有量词（Java 支持 ++）、限制输入长度，或改用非回溯的引擎/手写解析。（本站故障排查专栏有专门一篇。）

Q13：数据库连接池被打满了，可能的原因和处理？

参考回答要点：原因：慢 SQL 长期占用连接；事务中夹了远程调用/文件 IO，持有连接时间长；连接泄漏（忘记归还）；突发流量超过池大小；某租户批量任务霸占。排查：连接池监控（活跃/等待数）、数据库 show processlist、应用线程栈里大量线程卡在 getConnection。处理：止血（限流、kill 慢查询、降级）→ 找根因（缩事务、优化 SQL、开启泄漏检测，如 HikariCP 的 leakDetectionThreshold）→ 隔离（重任务独立数据源/池）。

踩坑：“把连接池调大”——池大到超过数据库承载能力只会把问题从应用挪到数据库。

Q14：讲讲你做过的一次“性能优化”，怎么证明有效？

参考回答要点：标准结构：现象与指标 → 定位方法 → 优化手段 → 前后对比 → 副作用。例如：订单列表接口 P99 2s → 链路追踪定位 N+1 查询和一条缺索引的 SQL → 批量查询 + 覆盖索引 + 热点字典缓存 → P99 降到 200ms → 副作用是缓存一致性窗口，加 TTL 与主动失效。

追问：“为什么不直接加缓存？”——缓存会带来一致性复杂度，先解决根因（SQL 与查询模式），再用缓存收尾；“怎么避免优化引入 bug？”——灰度、对比新旧结果、可开关回退。

Q15：你们有权限系统吗？RBAC 怎么设计？多租户下有什么特别之处？

参考回答要点：RBAC：用户 - 角色 - 权限（菜单/按钮/接口/数据范围）。SaaS 特殊点：角色与权限在租户内定义（租户管理员可自定义角色），平台级角色与租户级角色分离；数据权限（本人/本部门/本部门及下级/全租户）通过 SQL 拦截或统一查询构造器注入；鉴权要在服务端每次校验，不能只靠前端隐藏按钮。

追问：“权限缓存怎么失效？”——角色变更时按用户/租户维度主动清除，或用较短 TTL + 版本号；“越权漏洞怎么防？”——所有按 ID 查询的接口都要校验资源归属（水平越权，IDOR），可以在查询里带 tenant_id 与 owner 条件。

Q16：你在项目里遇到过的最棘手的数据问题？怎么修复、怎么避免？

参考回答要点：SaaS 里“脏数据”问题很常见：重复入账、状态卡在中间态、汇总与明细不一致。修复流程：先止血（暂停相关任务/加开关）→ 圈定影响范围（按租户、时间段、类型）→ 写幂等的修复脚本并先在测试/影子数据验证 → 分批执行、留备份与变更记录 → 复盘加对账与告警。避免：唯一索引、状态机、对账任务、幂等消费。

踩坑：直接在线上库手工 update；没有备份；修复脚本不可重跑。面试官对“线上直接改数据”非常敏感。

Q17：（开放题）你怎么评估一个需求的工作量与风险？

中级岗要开始有“交付意识”：拆到可验收的粒度（接口、表变更、迁移、联调、测试）；明确依赖与风险（第三方、数据迁移、兼容老版本客户）；预留 buffer 与回滚方案；对不确定点先做技术验证（spike）。说一个真实例子：“我们有个租户配置改造，原估 3 天，实际因为历史数据脏多花了 5 天，之后我做估算都会先抽样查数据质量。”

三点五、二面加餐：SaaS 业务里另外几个常被追的点

Q18：客户批量导入 Excel（几万行），你怎么设计？

参考回答要点：导入是 SaaS 最典型的“客户会乱传数据”的场景。设计要点：

1. 异步化：上传文件后立刻返回任务 ID，后台解析处理，前端轮询或推送进度；
2. 流式解析：不要把整个文件读进内存（EasyExcel 这类事件模型读取），分批（如 500 行）校验与入库；
3. 校验分层：格式校验（必填、类型）→ 业务校验（重复、外键存在）→ 落库；错误行收集成“错误报告”文件供客户下载修正，而不是遇到一行错就整体失败；
4. 幂等：以（租户, 业务唯一键）做唯一索引，重复导入执行 upsert 或跳过；
5. 限流与配额：单租户同时只允许 1–2 个导入任务，文件大小与行数有上限，避免占满资源。

追问：“导入到一半失败，已入库的怎么办？”——两种策略：全量回滚（适合数据量小、强一致）或部分成功 + 错误报告（适合大批量），要和产品对齐；“批量插入怎么写才快？”——JDBC 批处理（MySQL 需要 rewriteBatchedStatements=true 才会真正合并）、多值 insert、控制单批大小。

Q19：乐观锁和悲观锁，业务里怎么选？

参考回答要点：乐观锁（版本号/条件更新）适合冲突少的场景，失败后重试或提示用户；悲观锁（select … for update）适合冲突频繁且不能失败重试的场景，但要注意锁范围（走索引才是行锁，否则可能升级成表级影响）与死锁。例如：客户资料编辑用乐观锁（“数据已被他人修改，请刷新”）；余额扣减用条件更新 update account set balance = balance - ? where id = ? and balance >= ?，本质也是乐观思路，一条 SQL 即完成校验与扣减，不需要先查。

追问：“ABA 问题？”——版本号单调递增即可规避；“乐观锁重试风暴？”——限制重试次数，加退避，热点行考虑拆分或排队串行。

Q20：定时任务多实例怎么避免重复执行？任务失败了怎么办？

参考回答要点：方案：调度中心（XXL-Job、PowerJob 这类）统一调度，任务在执行器上按分片广播或单点路由；或者应用内 @Scheduled + 分布式锁。无论哪种，都要做到任务本身幂等：每次执行有业务批次号，处理前检查状态。失败：重试上限 + 告警 + 人工介入入口；“执行超时”要有回收机制；长任务拆成小任务，不要让一个任务跑几小时。

追问：“任务里租户很多，怎么遍历？”——分页取租户 ID 列表，逐租户处理，单租户失败不影响其他租户（try-catch + 记录失败租户），并且在日志里带租户 ID。

Q21：客户要“定制字段”，你怎么在多租户表里支持？

参考回答要点：常见做法有三种：（1）预留扩展列（ext1…extN），简单但类型和查询受限；（2）EAV 模型（实体-属性-值），灵活但查询和报表复杂、性能差；（3）JSON 列（MySQL 5.7+ 支持 JSON 类型，可用生成列 + 索引加速高频字段）。折中：核心字段用固定列，个性化字段用 JSON 存储，并在元数据表里记录每个租户的字段定义、校验规则与展示配置。

追问：“定制字段要参与筛选和报表怎么办？”——高频字段提为生成列建索引；报表场景把定制字段展开到宽表或分析库；“字段删除/类型变更？”——软删除字段定义，历史数据保留，类型变更走迁移任务。

Q22：发布与灰度：怎么降低“改一次全租户都受影响”的风险？

参考回答要点：SaaS 是单实例服务全体租户，一次坏发布影响面很大。手段：按租户灰度（白名单先开新功能，再逐步放量）、功能开关（出问题秒级关闭而不用回滚发布）、数据库变更向前兼容（先加列/双写，再切读，最后删旧列，即 expand/contract 模式）、发布后关注按租户维度的错误率与延迟、准备回滚预案。

追问：“新老版本同时在线，数据结构怎么兼容？”——先发布能读写新旧结构的版本，再执行迁移，最后清理；不要一个版本里同时“改表 + 依赖新表”。

Q23：单表数据几千万了，要不要分库分表？

参考回答要点：不要一上来就分。先看瓶颈是什么：查询慢（索引是否合理、是否深分页）、写入慢（索引过多、大事务）、存储大（历史数据是否可归档）。步骤通常是：优化索引与 SQL → 冷热分离/归档历史数据 → 读写分离 → 最后才是分库分表。行数不是唯一指标，“几千万行”在合理索引下 MySQL 仍能稳定服务，关键看单表大小、访问模式与增长速度。SaaS 场景下如果分片，分片键优先选租户 ID，因为绝大多数查询都带租户；代价是大租户数据倾斜，需要把超大租户单独迁出。

追问：“分片后跨租户统计怎么办？”——走离线/分析库，不在在线库做；“怎么平滑迁移？”——双写 + 数据校验 + 灰度切读，最后下线旧表。

Q24：日志和监控里，你觉得 SaaS 系统必须有哪些维度？

参考回答要点：每条日志与 trace 带 traceId、tenantId、userId；指标按租户维度看 QPS、错误率、P99、慢查询数；业务指标（导入成功率、批任务耗时、消息积压量）也要有告警。这样“某租户反馈慢”“某任务卡住”才能在五分钟内定位，而不是翻半小时日志。注意日志脱敏，不要打印手机号、证件号、token 等敏感信息。

四、HR 面要点（简）

中厂 HR 面更关心稳定性与匹配度：过去几段工作的时长与离职原因、期望薪资、入职时间、是否接受偶尔的紧急故障响应（SaaS 有客户，会有值班）。回答建议：离职原因讲成长与业务方向；薪资给区间并留有协商空间；对值班的态度要坦诚。背景核实环节保持与简历一致。

四点五、我的复盘点评：中级岗最容易丢分的三个地方

第一，把“会用”当成“懂”。Spring 事务、MyBatis 拦截器、线程池，这些三年经验的人都用过，但面试官问的是“它什么时候不生效”“出问题你怎么发现”。建议每个常用组件，都主动准备一个“我踩过的坑”，比如事务里调了 RPC 导致长事务占满连接池，或者异步线程里租户上下文丢了导致数据写到了默认租户。有真实的坑，回答就活了。

第二，只讲方案，不讲代价和边界。比如说到本地消息表，就要说“它带来了延迟、需要清理、需要消费端幂等”；说到预聚合，要说“它引入了汇总与明细的对账问题”；说到多租户共享表，要说“它的风险是漏写条件导致串数据，所以要靠框架拦截并加自动化测试覆盖”。能主动说出代价，面试官会觉得你做过。

第三，对“数据”缺乏敬畏。SaaS 面试官特别爱问修数据、迁移数据、批量更新怎么做。记住三句口诀：先备份、可回滚、分批做；脚本必须幂等、能重跑；上线前在影子数据上演练。这三句话能帮你避开一半的追问陷阱。

顺带一提，面经里常见的一个“反向提问”环节，中级岗可以问：“团队的租户规模和最大租户的数据量大概是什么量级？”“线上问题一般怎么值班和复盘？”这些问题既能判断团队成熟度，也能显示你关注的是工程质量而不是单纯的待遇。

五、这场面试暴露的通用规律

六、复盘清单与准备建议

1. 一致性：手画一遍“本地消息表”的时序图，能讲清哪一步失败会发生什么。
2. 多租户：回忆你项目里租户上下文如何在 Web、异步线程、MQ、定时任务四个入口传递，画成表。
3. 报表批处理：写出你业务中最大的一个批任务：数据量、分片方式、幂等键、失败恢复。
4. 排查：把“CPU 高、内存高、慢接口、连接池满”四条排查路径各背成一段话。
5. 项目：每个项目准备 3 个数字、2 个取舍、1 个遗憾、1 个如果重来会怎么做。

JavaGuide 的备考建议里强调：项目通常是技术追问的入口，复习要用“能讲结论、能扛追问、能对应到项目”三个层次自检。我觉得对中级岗特别适用：如果一个知识点你只能到第一层，面试里就是送分题变送命题。

再补一个小提醒：SaaS 公司对“责任心”很敏感。面试里讲到线上事故，不要把责任推到别人身上，讲清楚“我当时做了什么、学到什么、后来改了什么机制”，会比“我没有错”好得多。

一句话备忘：SaaS 中级岗 = 一致性靠“唯一索引 + 状态机 + 本地消息表 + 幂等”，多租户靠“统一上下文 + 自动拦截 + 分级隔离”，报表批处理靠“预聚合 + 分片幂等 + 断点续跑”，排查靠“先保现场再缩范围”。

本文再次强调：这是公开面经的整理与改编，不是某一场具体面试的实录。用它建立直觉，具体到你要面的公司，请以岗位描述和你自己的项目为准。

参考资料

• 腾讯云开发者社区《多租户的几种常用方案：从代码到架构的隔离》：共享表、独立 Schema、独立数据库三种隔离模式的优缺点与适用场景，以及动态数据源路由，本文 Q5 参考。
• 博客园《全网最全多租户系统设计方案》：竖井、共享、分域三种隔离模式与租户识别、计费计量等能力，本文“分域混合”思路参考。
• 牛客网《2026 Java 后端开发面试真题汇总》：事务隔离级别、索引优化、慢 SQL 排查、项目深挖题（最大挑战、重新设计、QPS 与瓶颈）的题型参考。
• 牛客网《阿里国际 java 社招一二面》：社招一二面的项目深挖、成长追问与流量突增场景题题型参考。
• JavaGuide《2026 最新版 Java 后端面试通关计划》：项目优先深挖、口述复习、问题跟踪表的备考方法，本文复盘清单参考。
• 小林coding《系统设计面试题》：接口超时排查路径、QPS 突增应对等要点，本文排查题参考。