🎙️ 第一輪：基礎構建與系統設計（3問）

面試官：我們先從一個實際業務場景開始。假設你現在要設計一個“雙十一秒殺系統”，用户搶購限量商品，你會怎麼選型技術棧？為什麼？

謝飛機：啊這……我肯定用 Spring Boot 啊！啓動快，配置少，還能打成 jar 包直接跑！數據庫嘛，MySQL 啊，我增刪改查賊6！

面試官：嗯……那你考慮過高併發下 MySQL 的瓶頸嗎？比如 10 萬用户同時點“立即購買”？

謝飛機：那我就多開幾個 MySQL 實例唄，主從複製，讀寫分離！我還知道分庫分表呢，sharding-jdbc 我背過面試題！

面試官：很好，有基本概念。但你有沒有想過，真正壓垮系統的往往不是數據庫，而是瞬間流量？

謝飛機：哦——那我加個 Nginx 做負載均衡！再上個 Redis 緩存熱門商品信息，這樣就不打數據庫了！

面試官：✅ 回答不錯！Redis 確實是第一步優化的關鍵。緩存熱點數據、預減庫存，都是常見手段。

🎙️ 第二輪：核心中間件與併發控制（4問）

面試官：好，那我繼續問。如果商品庫存只有 100 件，但 10 萬人搶，你怎麼保證不超賣？

謝飛機：簡單啊！我用 MySQL 的 UPDATE product SET stock = stock - 1 WHERE id = 1 AND stock > 0，靠數據庫行鎖不就行了？

面試官：如果請求量太大，數據庫扛不住怎麼辦？

謝飛機：那……那我就在代碼里加個 synchronized？

面試官：集羣環境下，synchronized 還管用嗎？

謝飛機：呃……好像只能鎖住當前 JVM？那我用 Redis 的 SETNX 實現分佈式鎖！key 是商品ID，value 是線程ID，釋放時判斷一下……

面試官：⚠️ 思路方向正確，但 SETNX 有原子性問題，而且沒設置過期時間會死鎖。建議用 Redisson 或 Lua 腳本實現可重入、帶過期的分佈式鎖。

面試官：再問，如果大量請求涌進來，系統快崩了，你怎麼處理？

謝飛機：我……我讓用户排隊？或者彈個“網絡繁忙，請稍後再試”？

面試官：這叫降級。更優雅的方式是結合 Sentinel 做限流，用滑動窗口或令牌桶算法控制 QPS。

🎙️ 第三輪：異步解耦與系統穩定性（5問）

面試官：現在你用了 Redis 鎖 + 數據庫扣減，但還是怕數據庫被打掛。有沒有更好的方案？

謝飛機：我……我可以先把訂單寫到日誌裏？等高峯過了再慢慢處理？

面試官：有點意思，你説的是“異步化”。具體用什麼中間件？

謝飛機：Kafka！我知道 Kafka 牛，高吞吐，削峯填谷！我把搶購請求發到 Kafka，後面用消費者慢慢消費，扣庫存、發短信、推通知！

面試官：✅ 正確！這就是典型的“消息隊列削峯”。但 Kafka 消費失敗了怎麼辦？

謝飛機：我……我讓它重試？100 次！

面試官：無限重試會導致消息堆積甚至雪崩。應該結合死信隊列（DLQ）+ 人工干預機制。

面試官：最後一個問題：如何監控整個鏈路性能？比如用户點擊到訂單生成耗時多久？

謝飛機：我……我看日誌？grep 一下 traceId？

面試官：可以，但效率低。你應該用 Zipkin + Sleuth 做分佈式鏈路追蹤，配合 Prometheus + Grafana 監控 Kafka 消費延遲、Redis 命中率等指標。

✅ 面試總結

面試官：今天的問題就到這裏。整體來看，你對主流技術有了解，但在高併發設計、容錯機制和監控體系上還需要加強。不過思路清晰，學習意願強，我們會盡快給你反饋，回去等通知吧。

謝飛機：（小聲嘀咕）等通知=沒戲……但我學到了 Redis 鎖不能只用 SETNX，還得設過期時間，最好用 Redisson……

💡 真題解析：電商秒殺系統的完整技術方案

🌐 業務場景：電商秒殺系統

• 用户在指定時間搶購限量商品
• 瞬時併發可達數萬甚至十萬級
• 核心目標：防超賣、高可用、低延遲、可追溯

🔧 技術架構圖（簡化版）

用户請求 → Nginx → API Gateway (Sentinel 限流)
                     ↓
             Spring Boot 服務集羣
                     ↓
        Redis（緩存熱點 + 分佈式鎖）
                     ↓
                 Kafka（異步削峯）
                     ↓
         消費者服務 → MySQL（最終落庫）
                     ↓
            Elasticsearch / Prometheus

🧩 關鍵技術點詳解

1. Redis 防超賣 & 分佈式鎖

• 使用 Lua 腳本保證原子性：先檢查庫存，再扣減，避免 GET + DECR 的併發問題
• 分佈式鎖推薦使用 Redisson，支持可重入、看門狗自動續期、公平鎖等特性
• 示例 Lua 腳本：

if redis.call('get', KEYS[1]) >= 1 then
    return redis.call('decr', KEYS[1]);
else
    return -1;
end

2. Kafka 削峯填谷

• 秒殺成功後，將訂單信息發送至 Kafka Topic
• 後台消費者服務異步處理：寫數據庫、發郵件、推消息
• 優勢：解耦、提高響應速度、防止數據庫瞬時壓力過大

3. 限流與降級（Sentinel）

• 設置 QPS 限制，如單機 1000 請求/秒
• 超過後返回“活動太火爆，請稍後再試”
• 結合熔斷機制，當數據庫異常時自動降級為“僅查看”模式

4. 鏈路追蹤（Sleuth + Zipkin）

• 每個請求生成唯一 traceId，貫穿上下游服務
• 可定位性能瓶頸，如 Kafka 消費延遲、Redis 超時等

5. 監控體系（Prometheus + Grafana）

• 監控指標包括：

• Redis 命中率、連接數
• Kafka Topic 積壓消息數
• JVM 內存、GC 頻率
• 接口平均耗時、錯誤率

📚 學習建議