今天面是被問一題，高併發你怎麼處理，我講完後對方不滿意，是後回想才知道對方需要我設立情境，啊我也沒什麼遇過，所以當下完全想像不到，我想說高併發不是後端要處理的嗎，問完AI後才發現前端也有其相對情境，雖然真正遇到時一樣半小時查一下就知道該怎麼寫，但這些公司就是很愛問，所以紀錄一下
前端高併發情境設計指南
在高併發情境下，前端的核心目標不再只是「呈現數據」，而是**「流量削峰」與「壓力隔離」**。透過將壓力擋在前端或邊緣端，可以有效防止後端資料庫因瞬間湧入的請求而崩潰。
核心設計原則
動靜分離：將不常變動的 HTML/JS/CSS 與靜態素材（圖片、影片）佈署於 CDN，減少對應用伺服器的直接請求。
請求削峰：利用緩衝、延遲或合併請求的方式，平滑化流量尖峰。
客戶端降級：當系統負載過高時，主動關閉非核心功能（如：預測搜尋、即時進度更新）。
代表性情境範例
1. 電商秒殺/搶購系統 (Rush Sale)
這是最典型的高併發情境，數百萬用戶在同一秒點擊按鈕。
前端應對策略：
按鈕防抖與置灰：點擊後立即禁用按鈕，防止重複送出請求。
靜態資源預熱：在活動開始前，利用 Service Worker 預先下載活動頁面所需的圖片與腳本。
排隊等待機制：前端發送請求後進入輪詢或 WebSocket 狀態，顯示「排隊中」而非直接報錯，提升用戶心理預期。
驗證碼與異步化：透過驗證碼強制拉長用戶的操作路徑，分散瞬間請求壓力。
2. 大數據流與無限捲動列表 (Infinite Scroll)
在社交平台（如 Threads、Instagram）或新聞資訊流，快速滑動會產生大量 API 請求。
前端應對策略：
虛擬列表 (Virtual List)：只渲染當前視窗（Viewport）可見的 DOM 節點。即使有 10 萬筆資料，記憶體中也只維持 10-20 個節點，避免瀏覽器崩潰。
分頁請求與預加載：設定滑動閾值，在用戶滑到剩下 20% 時才發送下一頁請求。
請求取消 (AbortController)：當用戶快速切換分類或滑動過快時，主動取消尚未完成的舊請求。
3. 即時互動與直播間彈幕 (Live Streaming Chat)
直播間數萬人同時發言時，頻繁的 DOM 更新與網路通訊是效能瓶頸。
前端應對策略：
彈幕池緩衝：不要收到一則彈幕就渲染一次。建立緩衝池（Buffer），每隔 500ms 批量渲染一次。
頻率限制與過濾：前端根據等級或關鍵字過濾次要訊息，或在本地限制用戶的發言頻率。
Canvas 渲染：針對海量彈幕，放棄使用 DOM 節點，改用 Canvas 繪製以獲得更高的渲染幀數。
總結技術清單
| 技術手段 | 解決的問題 | 應用範例 |
| CDN / Edge | 減少伺服器頻寬壓力 | 全域靜態檔案分發 |
| Service Worker | 離線緩存與預加載 | 秒殺頁面預熱 |
| Debounce / Throttle | 過度頻繁的觸發 | 搜尋框、視窗縮放 |
| Request Batching | 減少 HTTP 請求數量 | 點讚數合併計算 |
沒有留言:
張貼留言