---
name: backend
description: 后端怎么面（栈无关）：缓存、消息队列、接口、可靠性、可观测、容量、发布。服务端岗读。
keywords: [后端, 服务端, 后端开发, backend, backend engineer, 微服务, 分布式, 缓存, redis, 消息队列, kafka, 高并发, 限流, 可观测性, api设计, mysql, 数据库, 事务, 索引, dba, 分库分表]
layer: domain
---

## 面试官在意什么

后端工程师（服务端开发、Backend Engineer）的日常是把业务需求变成稳定、可扩展、可排查的线上服务：设计接口与数据模型、处理并发与一致性、接缓存与队列、盯监控与告警、扛流量高峰、处理线上故障。真实面试里，不论候选人写 Java、Go 还是 Python，被反复追问的都是同一批东西：数据怎么存、怎么读快、怎么写不丢、挂了怎么办、怎么知道它挂了、流量翻十倍先崩哪里。面试官最在意三件事：一是候选人能否说清自己系统里每个组件"为什么在那里"，而不是"大家都这么搭"；二是有没有真实的线上排查经历——从告警到根因的完整链路；三是对一致性、可用性、成本、复杂度之间的取舍有没有自己的判断，而不是背 CAP。

校招侧重基础：HTTP 与 RPC 的差别、缓存的基本用法、事务与锁、能否把一个简单业务拆成合理的表和接口，重点看思路是否清晰、能否被追问推着往下想。社招侧重工程判断：给一个具体故障或容量问题，看排查顺序、看有没有量化（QPS、P99、连接数、命中率）、看方案里有没有回滚与降级。一线大厂与外企近年更倾向于"场景推演"：给一个业务描述，让候选人现场设计并解释每个决定，纯名词题（"说说 Redis 的数据结构"）占比越来越低。

怎么问才像这个方向的面试官：
- 栈无关：本包只考人人必会的基础；语言细节、数据库内核、分布式一致性的深挖各在细节包里（java、go、mysql-internals、distributed-systems 等），JD 或简历落在上面时再读。
- 2026 年后端面试多了一条线：服务里接了大模型或 Agent 的候选人，会被追怎么给非确定性的调用做超时、重试、幂等、成本预算与缓存，和传统下游一视同仁的算没想过。
- 每道题必须有数字：候选人说了任何架构决策，追 QPS、数据量、延迟、机器数，用规模检验方案是否过度设计或设计不足。
- 优先考故障与取舍：不问"X 是什么"，问"X 坏了长什么样""为什么不用更简单的 Y"。
- 结合候选人项目规模出题：日活几千的项目不问分库分表，日活千万的项目必须追容量、降级与变更管理。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现"高并发" → 追具体 QPS、P99、机器数、瓶颈在哪一层、压测怎么做的；说不出数字的要标记
- 简历出现 Redis → 追缓存了什么、命中率、大 key/热 key 怎么处理、Redis 挂了系统会怎样、有没有出过缓存一致性事故
- 简历出现 Kafka/RocketMQ/RabbitMQ → 追消费幂等怎么做、堆积过没有、顺序有没有要求、分区数怎么定的
- 简历出现分库分表 → 追分片键、跨片查询怎么办、扩过容没有、为什么不先做归档或读写分离
- 简历出现微服务 → 追拆了几个、按什么拆、拆完最痛的问题是什么、有没有合并过
- 简历出现"性能优化 X%" → 追优化前后指标、怎么定位瓶颈、是不是压测环境的数字、上线后有没有回归
- 简历出现线上故障处理 → 追告警怎么发现、多久定位、根因是什么、事后改了什么机制
- 简历出现"接口设计" → 追幂等、分页、错误码、版本兼容怎么做的，有没有被上游重试打爆过
- 简历出现 MySQL 调优 / 慢 SQL → 追执行计划怎么读、索引怎么改、改后前后数字、有没有因为统计信息或参数误判
- 简历出现主从 / 高可用 / 数据迁移 → 追复制延迟怎么处理、切换过没有、脑裂怎么防、迁移的双写与校验方案

## 常见失守与危险信号

- 缓存设计与一致性：只会说"用 Redis 加缓存"；把延迟双删当标准答案却说不出它解决的是什么竞态；不知道自己系统缓存的命中率与 key 数量级
- 消息队列与异步解耦：认为 MQ 能保证恰好一次；消费端没有幂等设计；不知道自己 topic 的分区数、消费组、消费延迟指标
- 接口设计与 API 演进：认为接口设计就是命名规范；幂等靠"数据库唯一索引报错"却没考虑用户体验与并发；分页用 offset 到几百万页
- 可靠性：超时、重试、熔断、降级：所有调用共用一个线程池/连接池；重试没有上限没有退避；熔断阈值是拍脑袋的
- 可观测性与线上排查：排查全靠 grep 日志；不知道自己服务的 P99 是多少；告警多到没人看
- 限流、容量规划与压测：限流阈值不知道从哪来；压测只压单接口不压链路；扩容只加应用不看数据库连接数
- 存储选型与数据建模：什么都放 MySQL 或什么都放 MongoDB；双写却不处理失败；不知道 binlog 订阅这条路
- 配置、发布与变更管理：发布靠人肉；schema 变更与代码变更绑在一次发布里；没有回滚演练
- 安全与鉴权基础：认为 JWT 天然安全；鉴权散落在各个 controller；敏感数据明文存日志

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### 缓存设计与一致性
- 阶梯：为什么加缓存、放哪一层 → Cache Aside / Read Through / Write Behind 各自的适用场景，为什么"先删缓存再写库"会出问题 → 缓存击穿、穿透、雪崩在线上各自长什么样、怎么区分、怎么修 → 强一致与最终一致的边界：哪些数据可以容忍几秒不一致，哪些必须走数据库
- 答实的标志：能画出读写路径并指出竞态窗口；区分热 key、大 key 的处理（本地缓存、拆分、异步加载）；知道过期时间加随机抖动、互斥重建、布隆过滤器各解决什么问题；能说出哪些业务用了缓存但接受了什么程度的不一致

### 消息队列与异步解耦
- 阶梯：什么场景该异步 → 至少一次、至多一次、恰好一次各在哪一层保证，消费端幂等怎么做 → 消息堆积、消费者慢、重复消费、顺序错乱的排查与处理 → 削峰填谷带来的最终一致，业务上怎么向用户交代，什么场景不该用队列
- 答实的标志：幂等靠业务主键或去重表；堆积时有限流下游与动态扩容并存的方案；顺序需求用同一分区键保证并知道会牺牲并行度；死信队列与告警；能说出事务消息或本地消息表怎么保证"写库与发消息"一致

### 接口设计与 API 演进
- 阶梯：RESTful 与 RPC 怎么选 → 幂等键、分页游标、错误码体系、版本管理各自的设计 → 接口被上游重试打爆、老版本客户端无法下线怎么处理 → 内部接口用 gRPC/Thrift 还是 HTTP JSON，字段兼容规则怎么定
- 答实的标志：幂等键客户端生成、服务端先占位再处理；游标分页；错误码区分可重试与不可重试；字段只加不删不改语义；有接口文档与契约测试

### 可靠性：超时、重试、熔断、降级
- 阶梯：为什么每个远程调用都必须有超时 → 重试放大（retry storm）怎么发生，退避与抖动、重试预算 → 依赖服务变慢导致线程池耗尽、级联雪崩的排查 → 降级什么、保什么，怎么定义核心链路，预案怎么演练
- 答实的标志：按依赖隔离资源（线程池/信号量/连接池）；超时按链路预算逐级分配；熔断半开探测；降级有开关有兜底数据；能说出一次真实的雪崩与修复

### 可观测性与线上排查
- 阶梯：日志、指标、链路追踪各自回答什么问题 → RED/USE 指标怎么选，采样率与成本 → 告警了但日志里什么都没有、慢请求只在特定用户复现怎么查 → 告警噪音治理与 SLO 驱动的告警
- 答实的标志：先看变更（发布、配置、流量），再看依赖，再看资源；有 trace ID 贯穿；区分错误率、延迟、饱和度；提到告警要有 runbook；能讲出一次从告警到根因的完整过程

### 限流、容量规划与压测
- 阶梯：为什么要限流、限在哪一层 → 令牌桶、漏桶、滑动窗口的差别，单机限流与分布式限流 → 压测数据怎么造、怎么隔离、压测发现瓶颈在哪一层 → 容量按峰值备还是弹性扩，成本与 SLA 的取舍
- 答实的标志：从数据库、缓存、下游依赖逐层算容量；压测有影子库或流量标记；限流按用户/接口/租户分级并有优雅拒绝；热点隔离；提到预案与降级开关

### 存储选型与数据建模
- 阶梯：关系型、KV、文档、宽表、搜索、时序各适合什么 → 同一份数据多副本（主库 + ES + 缓存）怎么保持同步 → CDC/binlog 同步延迟、乱序、丢失的处理 → 多存储带来的一致性与运维复杂度值不值
- 答实的标志：按查询模式选存储；CDC 而不是双写；有对账任务；ES 降级回数据库简单查询

### 配置、发布与变更管理
- 阶梯：为什么大多数故障来自变更 → 灰度发布、蓝绿、金丝雀的区别，配置中心的动态推送 → 发布中新老版本共存导致的兼容问题、回滚时数据库 schema 怎么办 → 发布频率与稳定性的平衡，什么该自动化
- 答实的标志：先扩后缩的 schema 变更（加列、双写、切换、删列）；灰度按机器/用户比例并观察指标；配置变更也走灰度；变更记录可查

### 安全与鉴权基础
- 阶梯：认证与授权的区别 → session、JWT、OAuth2 各适合什么，JWT 怎么吊销 → 越权访问（横向/纵向）怎么在框架层统一防、接口被刷怎么处理 → 安全措施对性能与开发效率的影响
- 答实的标志：资源级权限校验在统一层；JWT 短有效期 + 刷新或黑名单；接口签名与风控；日志脱敏