面试时介绍项目亮点抓不住重点，一团乱麻？可以考虑从下面几个点出发，逻辑清晰，也能体现自己的思考

每个点讲几分钟加起来也能有小二十分钟，有效避免八股盛宴

具体是什么业务场景

有什么业务和技术上的瓶颈

你做了什么，怎么做的

遇到了什么问题，怎么解决的

有什么收益，怎么量化的收益

过程中有什么成长

举一个黑马点评的例子：

1. 业务场景

黑马点评的核心功能包括探店笔记发布、点赞、关注推送。比如用户发布探店笔记时，需要上传图片、索引内容到数据库，并展示用户头像、昵称、点赞状态。点赞功能需要处理高并发，同时展示点赞排行榜（按时间排序）。关注推送则是用户关注的达人发布新笔记后，粉丝能实时看到动态，用Redis的sorted set实现按时间分页查询

​2. 技术瓶颈

• ​数据库压力：点赞频繁导致MySQL频繁执行UPDATE和查询，出现慢查询和锁竞争（TPS仅500）。
• ​缓存穿透/雪崩：高并发查询未缓存的数据（比如新用户查不到笔记），导致数据库被打满。
• ​分布式锁问题：秒杀一人一单场景下，本地锁（如synchronized）在集群中失效，导致超卖。

​3. 解决方案与实施

点赞优化：

• 用Redis的sorted set替代普通set，用时间戳作为score，实现点赞排行榜的排序和分页查询。
• 解决分页顺序错乱：通过SQL的ORDER BY FIELD强制按Redis返回的ID顺序查询用户信。

缓存问题：

• ​穿透：缓存空值并设置随机过期时间（比如缓存NULL，过期时间30秒±5秒）。
• ​击穿：热点数据加锁，比如用Redis的SETNX实现互斥锁，保证只有一个线程重建缓存。

分布式锁：

• 用Redisson替代自研锁，解决可重入、锁续期问题。比如秒杀时，通过RLock锁用户ID，确保集群环境下的一人一单。

​4. 遇到的问题与解决

问题1：分页查询顺序错乱

• ​现象：从Redis sorted set查到的用户ID顺序正确，但数据库用IN查询后顺序乱了。
• ​解决：改SQL为ORDER BY FIELD(id, a,b,c...)，强制按传入ID顺序返回结果。

问题2：事务失效

• ​现象：@Transactional注解在同一个类的方法调用时不生效。
• ​解决：用AOP暴露代理对象，通过AopContext.currentProxy()调用方法。

​5. 量化收益

• ​性能提升：点赞接口QPS从500提升到8000，响应时间从200ms降到50ms。
• ​业务指标：秒杀活动超卖投诉率降为0，GMV增长320%。
• ​稳定性：缓存穿透导致的数据库压力下降90%。

​6. 个人成长

• ​技术深度：搞懂了CAP理论和最终一致性，比如用消息队列异步更新缓存和数据库，通过实现基于 Redisson 的分布式锁（含可重入、看门狗续期机制），结合 Lua 脚本保障原子性，优化锁粒度（如按商品 ID 细化），解决了超卖、锁误删及主从一致性问题。
• ​踩坑经验：学会用ThreadLocal存用户信息，避免在多线程中传递参数。
• ​协作能力：和前端联调时发现分页顺序问题，最终通过SQL优化解决，沟通效率提升。