上篇回顾1.6-01 用博客系统把前五章知识一次跑通从需求到 Docker 部署形成完整工程闭环。本篇接续——项目做完了但「怎么把项目经验变成面试弹药」是另一门学问。很多开发者项目做得不差简历写得像流水账面试一追就崩。一、开篇一份让面试官秒删的简历项目名称XX 博客系统 技术栈Spring Boot MyBatis Redis RabbitMQ Docker 项目描述使用 Spring Boot 搭建博客系统实现了用户注册登录、文章发布、评论等功能。 使用 Redis 做缓存使用 RabbitMQ 做消息队列使用 Docker 部署。这段描述的问题技术栈罗列面试官知道你用了什么但不知道你为什么用、怎么用、解决了什么问题功能清单式像产品说明书看不出技术深度没有量化QPS 多少响应时间多少优化前后对比统统没有没有难点面试官最想听的是「你遇到了什么坑、怎么解的」而不是「你做了什么功能」简历的核心不是「我做了什么」而是「我解决了什么问题、我怎么解决的、效果如何」。这就是 STAR 法则的价值。二、STAR 法则把流水账变成故事字母含义简历写法SSituation情境项目背景、业务场景TTask任务你负责什么、要解决什么AAction行动你怎么做的技术决策与实现RResult结果量化效果数据说话2.1 改造前 vs 改造后改造前流水账使用 Redis 做缓存提升了系统性能。改造后STAR文章详情接口 QPS 从 200 提升至 1500通过 Caffeine Redis 两级缓存将 95% 请求拦截在本地缓存层针对热点文章缓存击穿问题采用互斥锁 逻辑过期双保险方案压测下未出现穿透到 DB 的情况缓存与数据库一致性采用「先更新库再删缓存 延迟双删」策略最终一致延迟 1s。三个区别有数据200→150095%1s有决策为什么用两级缓存、为什么用互斥锁有深度击穿、穿透、一致性——每个都是面试官能追问的点2.2 STAR 的常见误区误区表现正确做法只写 A 不写 R「使用了 Redis 缓存」必须跟效果数据R 不可量化「性能大幅提升」给具体数字A 缺决策「用 RabbitMQ 异步」说为什么选 RabbitMQ 而不是 KafkaS 太冗长半页讲公司背景一句话说清场景三、技术难点的三层深度模型面试官最爱问「这个项目最难的地方是什么」你的回答要能撑住三个回合的追问。三层深度模型第一层现象发生了什么 ↓ 追问「为什么」 第二层原因根因是什么 ↓ 追问「怎么解的」 第三层方案你选了什么方案、为什么、代价是什么3.1 示例缓存击穿的三层深度第一层现象高并发下某个热点文章缓存过期瞬间大量请求打到 MySQL导致数据库连接池耗尽接口超时。第二层原因根因是热点 key 失效时没有互斥机制所有线程同时查库。缓存失效本身不可避免TTL 到了但「同时查库」可以避免。第三层方案用分布式锁做互斥——只有一个线程查库其他线程自旋等待。选 Redis 分布式锁而非 Zookeeper因为已有 Redis 依赖不想多引组件。代价是自旋会增加少量 RT但压测下 P99 只多了 5ms可接受。备选方案是「逻辑过期」不设 TTLvalue 里存过期时间后台异步刷新但实现更复杂本项目用互斥锁够了。3.2 常见难点的三层模板难点现象原因方案缓存穿透不存在的 ID 反复打库查不到不缓存布隆过滤器 空对象短 TTL分布式事务扣款成功记账失败本地事务管不到远程调用本地消息表 重试 幂等JWT 续期token 过期用户被踢短时效 无刷新机制双 tokenaccess refresh消息积压消费者跟不上生产者消费速度 生产速度临时扩消费者 限流降级四、性能优化的量化表达面试官对性能数据极其敏感。你说「优化了性能」不如说「QPS 从 X 提升到 Y」。4.1 量化表达的公式优化前指标 → 优化后指标 → 手段 → 代价示例文章列表接口 RT 从 800ms 降至 50msP99通过给created_at字段加复合索引消除全表扫描MyBatis 开启二级缓存减少 60% DB 查询前端分页从 20 条调到 10 条减少传输量。代价是索引增加了 5% 写入开销可接受。4.2 常见量化指标指标说明怎么测QPS每秒请求数JMeter / wrk 压测RT (P50/P99)响应时间APM 工具 / 日志统计内存占用JVM 堆 / off-heapjstat / jmapGC 频率Full GC 间隔GC 日志错误率5xx 比例Nginx 日志4.3 没有压测数据怎么办如果你是学习项目没做过线上压测本地压测也算。用 JMeter 或 wrk 在本机压一下给个相对数据本地 4C8G 环境下单实例 QPS 500P99 RT 80ms。诚实标注环境面试官不会苛求。但「没有数据」比「数据不够好看」严重得多——前者说明你没验证过后者只是资源有限。五、简历项目段落的完整模板项目名称XX 博客系统 | 个人项目 / 团队项目 | 2025.0X - 2025.0X 技术栈Java 17 / Spring Boot 3 / MyBatis-Plus / MySQL 8 / Redis 7 / RabbitMQ / Docker 项目背景S基于 Spring Boot 的博客系统支持文章发布、评论、用户认证等核心功能 目标为实践微服务架构下的高并发与数据一致性方案。 核心职责TAR 1. 设计并实现多级缓存方案Caffeine Redis文章详情接口本地压测 QPS 从 200 提升至 1500 P99 RT 50ms针对缓存击穿采用互斥锁方案压测下未出现 DB 穿透。 2. 实现评论异步削峰评论提交写入 RabbitMQ 后立即返回RT 50ms消费者异步落库 通过唯一 requestId 去重表保证幂等死信队列兜底失败消息。 3. 实现 JWT 双 token 鉴权access 30min refresh 7daccess 过期后前端自动用 refresh 续期 用户无感知refresh token 存 Redis 做服务端失效控制。 4. 设计库表三张user/article/comment核心字段加索引Docker compose 一键编排 appmysqlredishealthcheck 保证启动顺序。四条每条都遵循「做了什么 怎么做的 效果/细节」面试官随便挑一条都能追问下去。六、面试追问的防御策略面试官追问通常沿三条线6.1 深度线为什么这么选你用 Redis 分布式锁解决缓存击穿 追问为什么不用 Zookeeper 你已有 Redis 依赖不想多引组件 追问Redis 分布式锁有什么问题 你锁过期 业务未完成、主从切换丢锁 追问怎么解决 你看门狗续期Redisson Redlock 红锁防御策略每个技术选型至少准备两层「为什么」和一层「代价」。6.2 广度线还有什么方案你用本地消息表解决分布式事务 追问还有什么方案 你2PC、TCC、事务消息、Seata AT 追问你为什么不用 TCC 你TCC 业务侵入大每个接口要写 3 个方法 本项目并发不高本地消息表够用防御策略至少知道 3 种同类方案 各自优缺点。6.3 极限线极端场景怎么办你用 RabbitMQ 异步评论 追问消息积压 100 万条怎么办 你临时扩消费者 限流降级 追问消费者扩不了怎么办 你消息转存 告警 人工介入防御策略对每个方案准备一个「失效场景」和「兜底方案」。七、小结表维度流水账STAR 法则技术栈罗列决策理由功能清单解决的问题效果模糊量化数据难点无三层深度追问一问就崩撑三回合