项目经验面试指南¶

模板一（简洁版）:
项目名称：XXX系统
项目描述：[一句话说清楚项目做什么]
技术栈：[核心技术列举]
我的职责：
1. [职责1 + 技术点]
2. [职责2 + 技术点]
3. [职责3 + 技术点]
成果：[量化指标]

模板二（详细版）:
[项目背景] 在XX公司/场景下，为了解决XX问题，开发了XX系统。
[我的角色] 我在项目中担任XX角色，主要负责XX模块。
[技术方案] 使用了XX技术栈，核心挑战是XX，我通过XX方案解决。
[项目成果] 最终实现了XX效果，XX指标提升了XX%。

❌ 差的描述:
"我做了一个商城系统，用的Spring Boot + MySQL + Redis"
问题: 没有亮点，没有难度，没有量化成果

✅ 好的描述:
"负责电商平台的订单系统重构，日均处理50万+订单。
核心工作:
1. 设计了基于Redis + Lua脚本的库存扣减方案，解决了超卖问题
2. 引入消息队列实现订单异步处理，削峰填谷，降低数据库压力
3. 实现了分布式事务方案，保证订单-库存-支付的数据一致性
成果: 订单处理QPS从800提升到3500，超卖率降至0"

JD要求              →  简历项目应强调
-------------------------------------------
"高并发系统经验"     →  QPS、TPS、并发优化方案
"分布式系统经验"     →  微服务、消息队列、分布式事务
"大数据处理经验"     →  数据量级、批处理、实时计算
"搜索推荐经验"       →  ES、推荐算法、排序策略

✅ 好项目特征:
- 有明确的技术难点和解决方案
- 有性能优化的过程和结果
- 涉及系统设计和架构决策
- 有量化的业务指标

❌ 不适合放在简历上的项目:
- 纯CRUD、没有任何技术难点
- 跟着教程照抄的、无法深入讲解
- 完全不了解的项目（别人做的模块）

简历上放 2-3 个项目即可:
1. 第一个项目: 最匹配目标岗位JD的项目（重点展开）
2. 第二个项目: 展示不同技术栈/不同系统类型的项目
3. 第三个项目(可选): 个人项目/开源贡献/竞赛项目

[指标] 从 [基线值] 提升/降低到 [结果值]，提升/降低了 [百分比]%

1. 使用合理估算:
   "接口响应时间大约从几百毫秒级优化到百毫秒以内"

2. 使用定性描述:
   "显著降低了数据库查询压力"
   "解决了高峰期频繁超时的问题"

3. 使用对比:
   "优化前需要全表扫描, 优化后走索引, 查询时间从秒级降低到毫秒级"

4. 使用规模:
   "系统支撑了日均XX万订单的处理"

1. 描述困难: 具体的技术问题或业务挑战
2. 分析过程: 你是如何定位问题的
3. 解决方案: 你采用了什么技术方案
4. 最终效果: 问题解决后的效果
5. 经验总结: 从中学到了什么

[困难] 在电商大促期间，订单服务频繁出现超时，
      数据库CPU飙升至95%以上，导致下单失败率达到8%。

[分析] 我首先排查了监控大盘，发现数据库慢查询集中在订单查询和库存扣减。
      通过分析慢查询日志，发现有两个核心问题:
      1. 订单查询没有走正确的索引，存在全表扫描
      2. 库存扣减存在行锁等待，大量事务排队

[方案] 针对这两个问题，我分别采取了:
      1. SQL优化: 添加了联合索引, 将全表扫描改为索引覆盖查询
      2. 库存预扣: 引入Redis预扣库存方案，DB最终确认
         - 下单时先在Redis中扣减库存(原子操作)
         - 下单成功后异步更新DB库存
         - 使用Lua脚本保证Redis操作原子性
      3. 增加了数据库读写分离，查询走从库

[效果] 优化后数据库CPU下降到40%以下，接口响应时间从800ms降至100ms，
      下单成功率恢复到99.9%以上。

[总结] 这次经历让我深刻认识到:
      1. 线上问题排查要有方法论(监控→日志→复现→验证)
      2. 热点数据要用缓存抗压，不能全靠数据库
      3. 提前做好压测和容量评估

1. 需求分析: 我们的场景需要什么能力
2. 方案对比: 有哪些候选方案，各自的优劣
3. 选择理由: 为什么最终选择了这个方案
(可选) 4. 未来可能: 如果场景变化了会怎么调整

[需求] 我们的场景是订单系统的异步处理，
      核心需求是: 高吞吐量（日均500万+消息）、消息不丢失、消息顺序。

[对比]
      RabbitMQ:
      + 支持多种消息模式(直连/扇出/主题)
      + 消息确认机制完善
      - 吞吐量相对较低(万级)
      - 社区以Erlang为主，团队不熟悉

      Kafka:
      + 吞吐量极高(百万级)
      + 支持消息持久化和回溯
      + 分区有序，满足同一订单的顺序需求
      - 实时性不如RabbitMQ(毫秒级 vs 微秒级)

      RocketMQ:
      + 吞吐量高，功能丰富
      + 支持事务消息、延迟消息
      - 生态相对小，文档相对少

[选择] 最终选择了Kafka，主要因为:
      1. 我们最核心的需求是高吞吐量，Kafka最适合
      2. 对实时性要求不高(百毫秒级可以接受)
      3. 团队有Kafka的使用经验
      4. 公司基础设施已有Kafka集群

1. 先画整体架构（用户→网关→服务→存储）
2. 重点讲你负责的模块
3. 说清楚各组件的作用和数据流向
4. 主动提及技术难点和解决方案

整体架构(自顶向下):

用户端: Web/App/H5
    ↓
接入层: Nginx负载均衡 + API Gateway(路由/限流/鉴权)
    ↓
服务层: 微服务集群
  ├── 用户服务
  ├── 订单服务      ← 我主要负责
  ├── 商品服务
  ├── 支付服务
  └── 通知服务
    ↓                     ↓
数据层:                 中间件:
├── MySQL (主从)       ├── Redis (缓存/分布式锁)
├── ES (搜索)          ├── Kafka (异步消息)
└── MongoDB (日志)     └── Zookeeper (注册中心)

运维:
├── Docker + K8s (容器化部署)
├── Prometheus + Grafana (监控)
└── ELK (日志)

关于数据量:
"我们的订单表日增约50万条，总数据量约3亿条。
 商品表约100万条，SKU表约500万条。
 Redis缓存了约200万个热点商品信息。"

关于并发量:
"日均UV约100万，峰值QPS约5000，
 大促期间峰值QPS可达2万。
 核心接口(下单)P99响应时间要求<200ms。"

关于压测:
"我们使用JMeter进行全链路压测:
 1. 在预发布环境进行，使用影子库避免影响线上
 2. 从100并发逐步递增到2000并发
 3. 关注指标: QPS、RT、错误率、CPU/内存使用率
 4. 压测发现瓶颈:
    - 数据库连接池太小(20→50)
    - 某个接口有慢SQL(添加索引后解决)
    - Redis连接池配置不合理(调整maxTotal和maxIdle)
 5. 优化后系统稳定承压2万QPS"

诚实但有准备:
"我负责的系统日活约5万，QPS峰值约500。
 虽然并发量不算特别大，但我在系统设计时
 考虑了可扩展性:
 1. 使用了缓存减少数据库压力
 2. 核心操作使用了消息队列异步化
 3. 数据库做了读写分离
 4. 自己在测试环境用JMeter做过压测
 如果并发量增长10倍，我已经有预案..."

我在做这个项目的时候确实有一些遗憾或者可以改进的地方:

1. 架构层面:
   "当时用的单体架构, 如果重新设计,
    核心模块(订单/库存/支付)会拆分为微服务,
    提高独立部署和扩展能力。"

2. 技术方案:
   "当时库存扣减直接操作数据库,
    现在会用Redis预扣+消息队列异步确认的方案。"

3. 工程实践:
   "当时的监控比较简陋, 如果重新做,
    会引入完善的APM(如SkyWalking)和日志平台(ELK),
    方便快速定位线上问题。"

4. 代码质量:
   "有些模块的代码耦合度较高,
    现在会更注重领域驱动设计(DDD),
    用更清晰的分层和边界来组织代码。"

项目名称: 在线商城系统
技术栈: Spring Boot + MyBatis + MySQL + Vue
描述: 实现了商品展示、购物车、下单、支付等功能

问题: 太普通, 没有任何技术亮点, 和thousands of面试者的项目没有区别

项目名称: 高性能电商交易系统
技术栈: Spring Boot + MyBatis-Plus + MySQL + Redis + RabbitMQ + Vue

项目描述:
基于微服务架构设计的电商交易系统，支持商品管理、交易下单、
库存管控等核心电商能力。

我的职责:
1. 设计并实现了商品搜索模块
   - 使用Redis缓存热点商品数据, 缓存命中率95%+
   - 实现了缓存预热（定时任务加载TOP 1000商品）
   - 解决了缓存穿透（布隆过滤器）和缓存击穿（互斥锁）

2. 设计并实现了订单和库存模块
   - 使用Redis + Lua脚本实现原子化库存扣减, 防止超卖
   - 引入RabbitMQ实现订单异步创建, 削峰填谷
   - 实现了基于延迟消息的订单超时自动取消

3. 实现了接口限流和降级
   - 基于Guava RateLimiter实现接口限流
   - 使用Sentinel实现服务降级和熔断

成果:
- 商品查询接口响应时间<50ms
- 模拟压测下单接口支撑2000并发, 无超卖

Q: Redis缓存和数据库的数据一致性怎么保证的?
A: 我采用的是"先更新数据库, 再删除缓存"的策略(Cache-Aside Pattern)。
   为了解决删除缓存失败的问题, 增加了重试机制:
   如果直接删除失败, 将key发送到消息队列, 异步重试删除。
   对于短暂的不一致, 通过设置缓存过期时间(TTL=30秒)作为兜底。

Q: Lua脚本怎么实现的库存扣减?
A: Lua脚本保证了"判断库存→扣减库存"的原子性:
   if redis.call('get', KEYS[1]) >= ARGV[1] then
       return redis.call('decrby', KEYS[1], ARGV[1])
   else
       return -1  -- 库存不足
   end

   好处: Redis单线程执行Lua脚本, 天然原子性, 不需要加锁。

Q: 延迟消息是怎么实现的订单超时取消?
A: 使用RabbitMQ的死信队列(DLX)实现延迟消息:
   1. 创建一个TTL=30分钟的延迟队列(设定消息过期时间)
   2. 消息过期后自动转发到死信交换机
   3. 死信消费者接收到消息后, 检查订单状态
   4. 如果仍未支付, 关闭订单并释放库存

项目名称: XX公司后台管理系统
描述: 开发了用户管理、权限管理、数据报表等功能
技术栈: Spring Boot + MySQL + Vue + Element UI

问题: CRUD项目, 面试官看到就想跳过

项目名称: 企业级运营管理平台
技术栈: Spring Boot + Spring Security + MySQL + Redis + Vue + ECharts

项目描述:
服务于公司200+运营人员的综合管理平台，涵盖用户管理、
RBAC权限控制、数据分析报表等模块。

我的职责:
1. 设计并实现了RBAC权限管理模块
   - 基于Spring Security + JWT实现认证鉴权
   - 实现了菜单级、按钮级、数据级三级权限控制
   - 使用Redis缓存用户权限信息, 减少数据库查询
   - 实现了动态路由: 前端根据用户权限动态渲染菜单

2. 数据报表模块的性能优化
   - 原: 报表查询直接查主库, 数据量大时(500万+)响应超过10秒
   - 优化方案:
     a. 将报表查询切换到从库, 减少主库压力
     b. 对高频报表数据进行预计算, 结果存入汇总表
     c. 增加了查询缓存, 同一报表5分钟内使用缓存
   - 优化后: 报表加载时间从10秒降至1秒以内

3. 实现了操作日志审计功能
   - 基于AOP实现操作日志自动记录
   - 记录操作人、操作时间、操作内容、修改前后数据对比
   - 使用ELK进行日志检索和分析

成果:
- 系统服务200+运营人员, 日均操作量5000+
- 报表查询性能提升10倍
- 权限变更实时生效, 无需重新登录

Q: JWT的Token过期了怎么处理? 怎么实现无感刷新?
A: 我使用了双Token机制:
   Access Token(短期, 30分钟) + Refresh Token(长期, 7天)

   流程:
   1. 用户登录 → 下发Access Token + Refresh Token
   2. 正常请求携带Access Token
   3. Access Token过期 → 前端自动用Refresh Token请求新的Access Token
   4. Refresh Token也过期 → 需要重新登录

   无感刷新: 前端通过Axios拦截器实现:
   - 接口返回401 → 判断有Refresh Token → 静默刷新 → 重放失败请求

Q: 数据级权限是怎么实现的?
A: 使用MyBatis拦截器实现SQL自动改写:
   - 管理员: 可查看所有数据
   - 部门经理: 只能查看本部门数据 → SQL自动追加 AND dept_id = ?
   - 普通员工: 只能查看自己的数据 → SQL自动追加 AND user_id = ?

   这样业务代码不需要关心权限过滤, 由拦截器统一处理。

项目名称: 聊天室
描述: 基于WebSocket实现的在线聊天系统
技术栈: Node.js + Socket.io + MongoDB

项目名称: 分布式即时通讯系统
技术栈: Spring Boot + Netty + WebSocket + Redis + Kafka + MySQL

项目描述:
参考微信/钉钉的消息系统设计, 实现了支持单聊、群聊、
消息已读/未读、离线消息推送的即时通讯系统。

核心设计:
1. 通信层 — 基于Netty实现高性能长连接
   - 自定义协议编解码(协议头: 版本+消息类型+序列化方式+数据长度)
   - 使用Protobuf进行消息序列化(对比JSON, 体积减少约40%)
   - 实现心跳检测(IdleStateHandler), 及时清理断开的连接
   - 连接数: 单机测试支撑10000+长连接

2. 消息可靠投递
   - 消息发送方: 发送后进入"待确认"状态
   - 服务端: 存储消息 → 通过目标用户的Channel推送
   - 接收方: 收到后发送ACK → 服务端标记为"已送达"
   - 如果一定时间未收到ACK → 重试推送(最多3次)
   - 最终未送达 → 标记为离线消息, 用户上线后拉取

3. 分布式架构
   - 用户登录时, 将用户ID与所在服务器节点映射存入Redis
   - 跨节点消息: 发送方节点 → Kafka → 目标节点 → 推送给用户
   - 群消息: 扩散写(每个群成员一条) vs 扩散读(的优劣分析)
   - 我选择了扩散写, 因为群消息量远小于读取量

4. 离线消息
   - 使用Redis的SortedSet存储离线消息ID
   - Score为时间戳, 支持按时间范围拉取
   - 消息体存储在MySQL中
   - 用户上线后拉取离线消息(分页, 每次50条)

成果:
- 单机支撑10000+长连接
- 消息投递延迟P99 < 100ms
- 消息可靠性>99.99%(ACK+重试+离线缓存)

Q: 为什么用Netty而不是直接用Spring WebSocket?
A: 对比了两种方案:
   Spring WebSocket:
   + 开发简单, 和Spring生态集成好
   - 基于Tomcat/Jetty, 连接数受限(NIO模型但线程开销大)
   - 扩展性受限, 自定义协议不方便

   Netty:
   + 基于Reactor模型, 单机可支撑数万连接
   + 零拷贝和内存池, 性能更好
   + 自定义协议灵活(编解码器)
   + 丰富的Handler机制(心跳/断线重连/压缩)
   - 学习成本较高

   我的场景是即时通讯, 连接数多、消息频繁,
   Netty的高性能和灵活性更适合。

Q: 群聊的扩散写怎么理解? 和扩散读有什么区别?
A:
   扩散写(Write Diffusion):
     群里发一条消息 → 给每个成员的收件箱写一条记录
     读取时: 直接读自己的收件箱即可
     优点: 读取简单高效, 适合读多写少
     缺点: 写放大(群100人就写100条)

   扩散读(Read Diffusion):
     群里发一条消息 → 只存一条在群消息表
     读取时: 查询自己所有群的消息, 合并排序
     优点: 写入简单
     缺点: 读放大, 查询复杂

   我选择扩散写, 因为IM场景读远多于写,
   而且大部分群的人数不会太多(几十人到几百人)。
   如果是万人群, 会使用混合方案。

课程项目: 实现了一个简单的KV存储
描述: 用Go语言实现了Put/Get/Delete操作

项目名称: 分布式KV存储引擎
技术栈: Go + Raft + LSM-Tree + gRPC

项目描述:
受MIT 6.824课程启发, 独立实现了一个分布式KV存储系统,
支持强一致性读写和自动故障恢复。

核心实现:
1. 存储引擎 — LSM-Tree
   - MemTable(内存跳表) → Immutable MemTable → SSTable(磁盘)
   - 支持WAL(预写日志)保证崩溃恢复
   - 实现了Compaction(分层合并)减少读放大

2. 共识协议 — Raft
   - 实现了Leader选举、日志复制、安全性保证
   - 通过gRPC进行节点间通信
   - 3节点集群, 可容忍1个节点故障

3. 客户端
   - 实现了线性一致性读(读请求也走Leader)
   - 客户端自动重试和Leader发现

成果:
- 通过了MIT 6.824全部测试用例
- 写入吞吐量约5000 ops/s(3节点)
- Leader故障切换时间<3秒

技术选型回答公式:

需求分析 → 方案对比 → 选择理由 → 实际效果(可选)

"我们的场景是[具体需求/约束]，
 对比了[方案A]和[方案B]，
 [方案A]的优势是...，劣势是...
 [方案B]的优势是...，劣势是...
 最终选择了[方案X]，因为[与需求最匹配的理由]。
 实际使用效果是[量化结果]。"

选择MySQL的场景:
- 数据有明确的结构(Schema), 关系型数据, 需要事务
- 需要复杂的JOIN查询
- 数据一致性要求高(ACID事务)
- 例: 订单系统、用户系统、财务系统、库存系统

选择MongoDB的场景:
- 数据结构灵活, 字段经常变化(Schema-less)
- 读多写少, 大量的文档型数据
- 需要水平扩展(分片)
- 例: 日志系统、CMS内容管理、物联网数据、用户行为记录

回答示例:
"我们的用户行为日志系统选择了MongoDB, 原因是:
 1. 日志字段不固定, 不同业务线的日志格式差异大, MongoDB的灵活Schema更适合
 2. 日志量每天约2000万条, MongoDB的写入性能和分片能力可以满足
 3. 主要查询方式是按时间范围+用户ID查询, 不需要复杂JOIN
 4. 不需要事务支持

 而订单数据存在MySQL中, 因为:
 1. 订单涉及金额, 需要ACID事务保证一致性
 2. 订单和商品、用户之间有复杂的关联关系
 3. 需要精确的SQL查询和报表统计"

选择Redis的场景(绝大多数情况):
- 需要丰富的数据结构(String/Hash/List/Set/ZSet)
- 需要持久化
- 需要发布订阅、Lua脚本
- 需要分布式锁
- 例: 几乎所有缓存场景

选择Memcached的场景(少数情况):
- 纯KV缓存, 不需要复杂数据结构
- 需要多线程处理提高并发(Memcached多线程, Redis单线程)
- 缓存数据量超大, 追求极致的内存效率
- 例: 大规模会话缓存(Session)

回答示例:
"我们选择Redis作为缓存, 原因是:
 1. 需要使用Hash存储用户信息(部分字段更新效率高)
 2. 需要使用ZSet实现排行榜
 3. 需要使用分布式锁(库存扣减场景)
 4. 需要持久化, 服务重启后缓存数据不丢失
 5. 团队对Redis更熟悉, 运维有成熟的Redis集群方案"

┌───────────────┬──────────────┬──────────────┬──────────────┐
│    维度        │    Kafka     │  RabbitMQ    │  RocketMQ    │
├───────────────┼──────────────┼──────────────┼──────────────┤
│ 吞吐量        │ 百万级 ✅    │ 万级         │ 十万级       │
│ 延迟          │ 毫秒级       │ 微秒级 ✅    │ 毫秒级       │
│ 消息可靠性    │ 可配置       │ 高 ✅        │ 高 ✅        │
│ 事务消息      │ 支持(0.11+)  │ 不支持       │ 支持 ✅      │
│ 延迟消息      │ 不原生支持   │ 插件支持     │ 原生支持 ✅  │
│ 消息回溯      │ 支持 ✅      │ 不支持       │ 支持 ✅      │
│ 消息顺序      │ 分区有序     │ 队列有序     │ 队列有序     │
│ 社区生态      │ 大 ✅        │ 大 ✅        │ 国内大       │
│ 语言          │ Java/Scala   │ Erlang       │ Java         │
│ 适用场景      │ 大数据/日志  │ 业务消息     │ 电商/金融    │
└───────────────┴──────────────┴──────────────┴──────────────┘

选择Kafka的场景:
- 大数据量的日志收集和处理
- 流式计算(配合Flink/Spark)
- 需要消息回溯
- 高吞吐量优先

选择RabbitMQ的场景:
- 对延迟敏感, 需要微秒级延迟
- 需要复杂的路由(Exchange/Binding)
- 消息量不大但可靠性要求高

选择RocketMQ的场景:
- 电商/金融场景, 需要事务消息
- 需要延迟消息(如订单超时取消)
- 国内公司, 需要中文文档和社区支持

回答示例:
"我们的订单系统选择了RocketMQ, 原因是:
 1. 订单创建需要事务消息: 保证'创建订单'和'发送消息'的原子性
 2. 需要延迟消息: 订单30分钟未支付自动取消
 3. 吞吐量十万级满足我们日均百万订单的需求
 4. Java语言实现, 团队排查问题方便"

Spring Cloud:
+ 完整的微服务生态(注册中心/配置中心/网关/熔断/链路追踪)
+ Spring生态, 社区活跃, 文档丰富
+ HTTP通信(RESTful), 跨语言友好
- 调用性能不如RPC
- 组件选型多, 学习成本高

Dubbo:
+ RPC调用, 性能高(二进制序列化)
+ 服务治理能力强
+ 阿里经过大规模生产验证
- 生态不如Spring Cloud丰富
- 跨语言支持弱

回答示例:
"我们选择了Spring Cloud Alibaba, 结合两者的优势:
 - 使用Nacos作为注册中心和配置中心
 - 使用Sentinel做限流熔断
 - 使用OpenFeign做HTTP RPC调用
 - 使用Seata做分布式事务
 选择原因: 团队Java技术栈, Nacos和Sentinel在阿里经过大规模验证,
 社区活跃, 文档完善。"

选择单体架构:
- 项目初期, 业务简单, 团队小(5人以下)
- 快速验证MVP
- 不需要独立部署和扩展
- 运维能力有限

选择微服务架构:
- 业务复杂, 团队大(需要多团队独立开发)
- 需要独立部署和扩展
- 需要技术栈多样性
- 有成熟的DevOps和基础设施

回答示例:
"我们最初是单体架构, 随着业务增长到以下问题将部分模块拆分为微服务:
 1. 订单模块改动频繁, 每次都要全量发布, 影响其他模块
 2. 大促时只有订单模块需要扩容, 单体架构要整体扩容, 浪费资源
 3. 团队扩展到30人, 代码冲突严重

 拆分方案:
 - 按业务域拆分: 用户服务、商品服务、订单服务、支付服务
 - 服务间通过OpenFeign调用
 - 数据库独立(每个服务有自己的数据库)
 - 使用Kafka做异步解耦"

准备方法:
1. 简历上出现的每个技术, 都要能讲清楚原理
2. 不会的不要写在简历上!
3. 用"是什么→为什么→怎么做"的框架回答

回答模板:
"[是什么] XX技术是用来解决XX问题的方案,
 [为什么] 之所以用它是因为XX,
 [怎么做] 它的核心原理是XX, 在我的项目中, 具体的使用方式是XX"

✅ 好的回答:
"分布式锁这块我们使用的是Redisson框架。
 选择Redisson是因为它实现了看门狗自动续期,
 解决了锁超时导致业务未完成就释放的问题。
 我阅读过Redisson的加锁源码,
 它底层是通过Lua脚本保证加锁和设置过期时间的原子性,
 看门狗通过定时任务(每10秒)自动续期30秒。
 在实际使用中, 我还针对我们的场景做了一层封装..."

❌ 差的回答:
"我用的Redisson, 调一下lock()就行了"

回答模板:
"我们团队[X]个人, 后端[X]个, 前端[X]个。
 我主要负责[核心模块1]和[核心模块2]。
 [核心模块1]中我具体做了:
 1. XX功能的设计和实现
 2. XX问题的排查和优化
 [核心模块2]中我主要做了:
 1. XX
 其他模块(如XX)由同事负责, 但我了解整体架构和接口定义。"

注意:
- 不要说"全部是我做的"(面试官不信)
- 不要把别人的工作说成自己的(容易被戳穿)
- 了解你负责模块的上下游交互

回答模板:
"这个项目确实有两个可以改进的地方:

 1. [技术层面的不足]
    当时由于时间紧张, XX模块的实现比较简单,
    如果有机会, 我会用XX方案来替代,
    可以获得XX方面的改善。

 2. [工程层面的不足]
    当时的XX做得不够好,
    后来我学习了XX, 意识到应该...

 这些不足也是我成长的方向,
 我在后续项目中已经做了XX改进。"

注意:
- 不足要"可控"(不是致命缺陷)
- 每个不足都要有"改进方向"
- 展示你的学习和进步

第一轮: 项目介绍 (5分钟)
面试官: "介绍一下你最近做的项目"
你: [STAR法则, 2-3分钟讲完, 突出技术亮点]

第二轮: 技术深挖 (10-15分钟)
面试官: "你说用了Redis缓存, 缓存策略是什么?"
面试官: "如何保证缓存和数据库的一致性?"
面试官: "如果Redis挂了怎么办?"
[层层深入, 考察深度]

第三轮: 系统设计 (5-10分钟)
面试官: "如果用户量增长100倍, 你的系统怎么改?"
面试官: "你的系统有什么瓶颈? 如何优化?"
[考察架构思维和扩展性]

第四轮: 反思改进 (3-5分钟)
面试官: "如果重新设计, 你会做什么不同的选择?"
面试官: "从这个项目中你学到了什么?"
[考察成长性和思考深度]

1. 自信但不自大
   - 对自己做的模块要有信心, 能深入讲解
   - 不了解的坦诚说不了解, 但可以说出推测和学习方向

2. 逻辑清晰
   - 回答有框架: "这个问题我从三个方面来说"
   - 先总后分, 先结论后分析

3. 主动引导
   - 在项目介绍时, 主动提到你准备充分的技术点
   - 面试官往往会沿着你提到的点深入问

4. 适时举例
   - 抽象概念 + 具体例子 = 最佳回答
   - "以我项目中的场景为例..."

5. 展示思考过程
   - 不要直接给答案, 展示你的分析过程
   - "首先我会分析..., 然后我会考虑..., 最终我的方案是..."

□ 项目背景和架构图 (1分钟能说清)
□ 你的具体职责 (不要模糊)
□ 2-3个技术亮点 (每个能讲5分钟)
□ 核心技术的原理 (不是只会用API)
□ 性能数据和量化指标 (有数据支撑)
□ 遇到的问题和解决过程 (STAR法则)
□ 可能的追问和应对方案 (至少准备5个)
□ 架构的优缺点和改进方向 (展示反思)
□ 技术选型的理由 (为什么用这个不用那个)
□ 系统如何扩展 (如果量增长10倍怎么办)

亮点名称: [例: Redis + Lua脚本实现库存扣减]

1. 背景:
   [为什么需要这个方案? 原来的问题是什么?]

2. 技术选型:
   [对比了哪些方案? 为什么选择这个?]

3. 实现细节:
   [核心代码/算法/数据结构是什么?]

4. 效果:
   [量化指标, 解决了什么问题]

5. 踩坑经历:
   [实现过程中遇到的问题及解决]

6. 可能追问:
   [面试官可能问什么? 你怎么回答?]

□ 再次阅读目标公司的JD, 确认项目亮点与JD匹配
□ 用自己的话把每个项目说一遍(计时, 控制在3分钟以内)
□ 检查简历上每个技术关键词, 确认能讲清楚原理
□ 准备3个有代表性的技术难题和解决过程
□ 准备1-2个你想问面试官的问题
□ 检查你的GitHub/作品集链接是否正常
□ 准备好纸笔, 可能需要画架构图

面试常问: "设计一个秒杀系统"

核心挑战: 高并发、防超卖、保证公平

关键设计:
1. 前端: 按钮防重复点击 + 静态化CDN
2. 接入层: Nginx限流 + 验证码/答题(削峰)
3. 服务层:
   - Redis预扣库存(Lua脚本原子操作)
   - 请求排队(MQ)
   - 异步下单
4. 数据层:
   - 库存预加载到Redis
   - 订单异步写入DB
5. 防刷: 令牌桶限流 + IP限制 + 黑名单

面试常问: "你们项目中怎么解决分布式事务的?"

常见方案:
1. 最终一致性(消息队列):
   本地事务 + 可靠消息 + 消费端幂等
   适用: 大部分异步场景

2. TCC(Try-Confirm-Cancel):
   适用: 强一致性、金融交易场景

3. Seata AT模式:
   适用: 对业务入侵小的场景

4. Saga:
   适用: 长事务、流程型业务

回答模板:
"我们项目中的分布式事务场景是: 下单时需要同时扣减库存和创建订单,
 这两个操作在不同的服务中。

 我们采用的是基于消息队列的最终一致性方案:
 1. 订单服务创建订单(本地事务)
 2. 同时发送'扣减库存'消息到MQ(事务消息确保和本地事务原子性)
 3. 库存服务消费消息, 扣减库存
 4. 如果扣减失败, 重试3次后进入死信队列, 人工介入
 5. 消费端做了幂等处理(基于唯一消息ID)

 选择这个方案是因为:
 - 下单和扣库存之间不要求强一致性(短暂的不一致可接受)
 - MQ的方案性能最好, 不会阻塞主流程
 - 实现相对简单, 团队维护成本低"

面试常问: "一个接口响应太慢, 你怎么优化?"

排查思路:
1. 确定瓶颈: 是CPU/内存/IO/网络?
2. 慢在哪: 数据库? 远程调用? 计算?

常见优化方法:
┌────────────────┬─────────────────────────────────────────────┐
│ 层面           │ 优化方案                                     │
├────────────────┼─────────────────────────────────────────────┤
│ 代码层         │ 减少循环查DB(N+1问题), 避免重复计算           │
│ 缓存层         │ Redis缓存热数据, 本地缓存(Caffeine)          │
│ 数据库层       │ SQL优化、索引优化、分库分表、读写分离         │
│ 架构层         │ 异步化(MQ)、并行化、预计算                   │
│ 网络层         │ 减少序列化大小、压缩、连接池(避免频繁建连)    │
│ JVM层          │ GC调优、堆大小调整                           │
└────────────────┴─────────────────────────────────────────────┘

回答模板:
"我之前优化过一个用户信息详情接口, 原本响应时间约2秒:

 1. 分析: 通过APM链路追踪发现, 该接口查了5次数据库,
    其中3次可以合并, 2次是N+1问题造成的循环查询

 2. 优化:
    a. 合并查询: 5次DB查询优化为2次(批量查询)
    b. 缓存: 用户基本信息加了Redis缓存(TTL=5分钟)
    c. 并行: 2次独立查询改为并行(CompletableFuture)
    d. 字段裁剪: 只查询需要的字段, 减少数据传输量

 3. 效果: 响应时间从2秒降低到120ms
    - 缓存命中时: 50ms
    - 缓存未命中: 120ms"