面試時介紹項目亮點抓不住重點，一團亂麻？可以考慮從下面幾個點出發(fā)，邏輯清晰，也能體現(xiàn)自己的思考

每個點講幾分鐘加起來也能有小二十分鐘，有效避免八股盛宴

具體是什么業(yè)務場景

有什么業(yè)務和技術上的瓶頸

你做了什么，怎么做的

遇到了什么問題，怎么解決的

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

過程中有什么成長

舉一個黑馬點評的例子：

1. 業(yè)務場景

黑馬點評的核心功能包括探店筆記發(fā)布、點贊、關注推送。比如用戶發(fā)布探店筆記時，需要上傳圖片、索引內(nèi)容到數(shù)據(jù)庫，并展示用戶頭像、昵稱、點贊狀態(tài)。點贊功能需要處理高并發(fā)，同時展示點贊排行榜（按時間排序）。關注推送則是用戶關注的達人發(fā)布新筆記后，粉絲能實時看到動態(tài)，用Redis的sorted set實現(xiàn)按時間分頁查詢

?2. 技術瓶頸

• ?數(shù)據(jù)庫壓力：點贊頻繁導致MySQL頻繁執(zhí)行UPDATE和查詢，出現(xiàn)慢查詢和鎖競爭（TPS僅500）。
• ?緩存穿透/雪崩：高并發(fā)查詢未緩存的數(shù)據(jù)（比如新用戶查不到筆記），導致數(shù)據(jù)庫被打滿。
• ?分布式鎖問題：秒殺一人一單場景下，本地鎖（如synchronized）在集群中失效，導致超賣。

?3. 解決方案與實施

點贊優(yōu)化：

• 用Redis的sorted set替代普通set，用時間戳作為score，實現(xiàn)點贊排行榜的排序和分頁查詢。
• 解決分頁順序錯亂：通過SQL的ORDER BY FIELD強制按Redis返回的ID順序查詢用戶信。

緩存問題：

• ?穿透：緩存空值并設置隨機過期時間（比如緩存NULL，過期時間30秒±5秒）。
• ?擊穿：熱點數(shù)據(jù)加鎖，比如用Redis的SETNX實現(xiàn)互斥鎖，保證只有一個線程重建緩存。

分布式鎖：

• 用Redisson替代自研鎖，解決可重入、鎖續(xù)期問題。比如秒殺時，通過RLock鎖用戶ID，確保集群環(huán)境下的一人一單。

?4. 遇到的問題與解決

問題1：分頁查詢順序錯亂

• ?現(xiàn)象：從Redis sorted set查到的用戶ID順序正確，但數(shù)據(jù)庫用IN查詢后順序亂了。
• ?解決：改SQL為ORDER BY FIELD(id, a,b,c...)，強制按傳入ID順序返回結果。

問題2：事務失效

• ?現(xiàn)象：@Transactional注解在同一個類的方法調(diào)用時不生效。
• ?解決：用AOP暴露代理對象，通過AopContext.currentProxy()調(diào)用方法。

?5. 量化收益

• ?性能提升：點贊接口QPS從500提升到8000，響應時間從200ms降到50ms。
• ?業(yè)務指標：秒殺活動超賣投訴率降為0，GMV增長320%。
• ?穩(wěn)定性：緩存穿透導致的數(shù)據(jù)庫壓力下降90%。

?6. 個人成長

• ?技術深度：搞懂了CAP理論和最終一致性，比如用消息隊列異步更新緩存和數(shù)據(jù)庫，通過實現(xiàn)基于 Redisson 的分布式鎖（含可重入、看門狗續(xù)期機制），結合 Lua 腳本保障原子性，優(yōu)化鎖粒度（如按商品 ID 細化），解決了超賣、鎖誤刪及主從一致性問題。
• ?踩坑經(jīng)驗：學會用ThreadLocal存用戶信息，避免在多線程中傳遞參數(shù)。
• ?協(xié)作能力：和前端聯(lián)調(diào)時發(fā)現(xiàn)分頁順序問題，最終通過SQL優(yōu)化解決，溝通效率提升。