项目详细拷打

一、项目概述

回答模板：

“我负责的是基于Spring Boot的校园点餐系统，分为客户端（微信小程序）和商家端（Web管理后台）。核心功能包括在线点餐、订单管理、高并发库存控制、实时通知等。我重点解决了分布式锁防超卖、JWT无状态认证、Redis缓存优化、WebSocket实时通信等技术难点。”

二、技术点拆解与追问预测

1. 登录与身份验证（JWT + ThreadLocal）

引导问题：
• 为什么选择JWT而不是Session？
• 如何保证Token的安全性？
• ThreadLocal可能有什么风险？

技术要点：
• JWT结构：Header（算法）、Payload（用户数据）、Signature（签名防篡改）。
• 无状态优势：适合分布式系统，减少服务端存储压力。
• 安全问题：
• Token泄露风险 → 结合HTTPS、设置较短过期时间。
• 主动失效困难 → 用Redis维护黑名单（如用户注销时记录未过期的Token）。
• ThreadLocal内存泄漏：
• 原因：Tomcat线程池复用线程，未remove()导致用户信息残留。
• 解决：拦截器销毁前调用ThreadLocal.remove()。

2. 分布式锁（Redis + Lua）

引导问题：
• 为什么用Lua脚本？
• 锁的过期时间设置多久？如何续期？
• 是否会出现锁误删（删了别人的锁）？

技术要点：
• Lua原子性：确保setnx + expire操作原子执行，避免死锁。
• 锁误删风险：
• 场景：线程A超时释放锁，但仍在执行业务 → 线程B获锁，A完成后误删B的锁。
• 解决：锁value存储唯一标识（如UUID），删除前校验标识。
• 续期问题：
• 未实现续期 → 业务执行时间超过锁过期时间会导致锁失效。
• 改进方案：使用Redisson的watchDog机制自动续期。

3. Redis缓存（菜品缓存 + 内存优化）

引导问题：
• 缓存和数据库如何保证一致性？
• 为什么用Hash结构存储用户信息？
• 遇到过缓存穿透/雪崩吗？如何解决？

技术要点：
• 缓存一致性：
• 方案：更新数据库后删除缓存（而非更新缓存），下次查询时重建。
• 潜在问题：删除缓存失败 → 通过消息队列重试。
• Hash结构优势：
• 节省内存：Hash的ziplist编码在字段少时压缩存储。
• 部分更新：可单独修改某个字段（如用户昵称），而String需要反序列化整个对象。
• 缓存雪崩：
• 现象：大量缓存同时过期 → 请求压到数据库。
• 解决：随机过期时间（基础时间 + 随机偏移量）。

4. WebSocket实时通信（来单提醒/催单）

引导问题：
• WebSocket和HTTP轮询有什么区别？
• 如何保证消息的可靠传输（比如断网了怎么办）？
• 服务端如何管理大量连接？

技术要点：
• 对比HTTP轮询：
• WebSocket：长连接双向通信，减少无效请求，适合实时场景。
• HTTP轮询：频繁建立连接，延迟高。
• 断线重连：
• 客户端监听onclose事件，尝试重连并重新订阅。
• 服务端记录会话状态，重连后补发未确认消息（需业务设计消息ID）。
• 连接管理：
• 使用ConcurrentHashMap或Redis存储在线用户与Session的映射。

5. Spring Task定时任务（订单超时取消）

引导问题：
• 分布式环境下多个服务节点会重复执行任务吗？
• 任务执行时间长导致阻塞怎么办？
• 有没有更好的方案替代Spring Task？

技术要点：
• 分布式问题：
• 多个节点同时执行任务 → 通过Redis分布式锁或数据库乐观锁保证唯一性。
• 阻塞问题：
• 原因：Spring Task默认单线程执行任务 → 使用@Async+线程池异步处理。
• 替代方案：
• XXL-JOB：支持分片任务、动态扩容、失败重试。
• RabbitMQ延迟队列：订单创建时发送延迟消息，到期后消费消息取消订单。

6. 分布式Session（Redis + Hash）

引导问题：
• 为什么用Redis存Session？和Tomcat Session对比有什么优势？
• Hash结构比String具体节省多少内存？如何验证的？
• 集群环境下Redis挂了怎么办？

技术要点：
• Redis优势：
• 跨服务共享Session，支持水平扩展。
• 对比Tomcat Session：无需粘性会话，适合集群部署。
• 内存优化验证：
• 用redis-memory-analyzer工具分析String和Hash的内存占用差异。
• 例如：用户对象有10个字段 → String存JSON需1KB，Hash用ziplist编码可能仅500B。
• 高可用：
• Redis主从集群 + Sentinel故障转移。
• 多级缓存：本地缓存 + Redis，避免Redis不可用时完全崩溃。

三、项目扩展问题预测

系统性能数据：
• “缓存优化后，QPS从多少提升到多少？”
• “分布式锁减少超卖多少百分比？”
• 回答建议：给出量化结果（如缓存命中率从30%→90%，超卖率从5%→0.1%）。
技术选型对比：
• “为什么选MyBatis而不是JPA？”
• “为什么不用Kafka而用Redis做消息队列？”
• 回答建议：结合业务场景（如MyBatis灵活SQL优化，Redis轻量且已有基础设施）。
系统设计缺陷：
• “如果订单量增加10倍，系统哪里会先崩？如何优化？”
• 回答建议：分库分表（用户ID分片）、订单表冷热分离、Redis集群扩容。

四、回答技巧

STAR法则：
• Situation：项目背景（如高并发点餐场景）。
• Task：你负责的功能（如防止超卖）。
• Action：具体技术方案（Redis分布式锁 + Lua）。
• Result：量化结果（超卖率下降至0.1%）。
主动引导：
• 如果面试官问题模糊，可主动展开：“需要我详细说明分布式锁的实现吗？”
承认不足：
• 如果被问到未考虑的漏洞，可回答：“当时确实没考虑到这点，后续可以通过XX方案改进。”