一文整理：并發請求隔離的常見誤區與最佳實踐
線上系統最危險的時刻，往往不是“并發變高”，而是某個環節開始變慢后，慢請求互相拖死：線程池被占滿、連接池被打滿、下游依賴超時，最后演變成級聯雪崩。
很多同學第一反應是“擴容/加機器”，但在 1–3 年階段更該補的，是一套可落地的并發請求隔離：把擁塞關在局部，不讓它擴散到全站。
這篇我用“全景圖 + 落地順序 + 自查清單”的方式，把限流、排隊、熔斷、降級、線程池隔離、無狀態化串成一條可執行路線，照著做就能明顯提升穩定性與抗壓能力。
01 為什么“并發高”不致命，“互相拖死”才致命
并發本身不是原罪。可怕的是：當某個依賴變慢（數據庫、第三方接口、緩存 miss、磁盤 IO），請求開始堆積，隨后引發連鎖反應：
- 線程池隊列越堆越長 → 請求等待時間暴漲
- 連接池被占滿 → 新請求拿不到連接
- 上游重試/客戶端重試 → 流量進一步放大
- 最終：原本健康的接口也被拖垮（“全站抖動”）
結論一句話：并發治理的核心不是“扛住所有請求”，而是“控制擁塞傳播”。
02 并發隔離到底在隔離什么？（一句話講清）
并發隔離 = 給不同類型的請求、不同依賴、不同資源池劃邊界。
讓慢的、重的、不穩定的那部分“自己慢/自己失敗”，不要把核心鏈路一起帶走。
你可以把隔離理解成：
- 給系統裝“隔離艙門”（限流/熔斷/超時）
- 給資源劃“不同車道”（線程池/連接池/隊列分離）
- 給業務定“優先級”（核心鏈路先活）
03 并發治理 6 件套：從入口到資源層的全景圖（重點收藏）?
下面這 6 類，從外到內覆蓋“入口 → 執行 → 依賴 → 數據 → 業務優先級”。（截圖中提到的限流、隊列、優雅降級、服務標簽/策略、自定義執行器等，我都在這里做了工程化重排。）
3.1 入口隔離：限流（保護系統上限）
你要回答 3 個問題：對誰限？限多少？限了怎么辦？
要點清單：
- 限流維度：接口/用戶/租戶/IP/設備/全站
- 返回策略：直接拒絕（429）/返回降級數據/引導重試（帶抖動）
- 保護對象：線程池、DB、第三方依賴（誰最脆弱就先護誰）
常見坑：全局一刀切，把核心用戶/核心鏈路也限掉。
3.2 排隊隔離：隊列/異步化（削峰填谷）
適用場景：允許延遲的任務（通知、報表、風控、異步計算等）。
要點清單：
- 隊列不是“萬能蓄水池”，要有：最大長度、超時、丟棄/降級策略
- 消費端要做：冪等、重試退避、死信隊列（別把重試變成二次洪峰）
常見坑：只上隊列不做“堆積告警”，最終“隊列把 DB 壓死”。
3.3 執行隔離：線程池/執行器隔離（防止互相搶資源）
當一個服務里同時有“快接口”和“慢接口”，最容易互相拖死。
要點清單：
- 核心接口單獨線程池（小而穩），非核心接口另起線程池（可被擠壓）
- 配合：隊列長度上限 + 任務超時 + 拒絕策略（不要無限排隊）
- 自定義執行策略/執行器：把“不同工作負載”拆到不同資源池里
常見坑：線程池越拆越多，參數拍腦袋，壓測一來全亂。
3.4 依賴隔離：超時 + 熔斷（防止下游把你拖死）
對外部接口、弱依賴、抖動依賴，一定要把“等待”限制住。
要點清單：
- 超時要“分層”：客戶端/服務端/下游都要有（別只配一個地方）
- 熔斷觸發：錯誤率、超時率、慢調用比例
- 熔斷后必須有：降級返回（兜底數據/默認值/緩存結果）
常見坑：只熔斷不降級 → 用戶體驗仍然災難。
3.5 數據隔離：緩存/DB 保護（別讓熱點打穿）
熱點與緩存 miss 往往是并發事故的導火索。
要點清單：
- 緩存策略：防穿透/防擊穿/防雪崩（核心是“保護 DB”）
- DB 保護：慢查詢治理、連接池保護、讀寫分離/限速、關鍵表優先
常見坑：只做緩存命中率，不做“DB 壓力閾值告警”。
3.6 業務隔離：分級服務（核心鏈路優先活）
并發上來時，“所有功能都可用”幾乎不現實，你需要優先級。
要點清單：
- 分級示例：下單/支付 > 詳情頁 > 推薦 > 埋點/畫像
- 必備：降級開關（可灰度）、降級預案、回滾策略
- 目標：核心鏈路在高壓下仍可用（哪怕功能變少）
常見坑：沒有預案，事故來了只能“硬扛”。
04 最容易踩的 8 個坑（很多人限流了還是崩）
- 只做入口限流，不做線程池/連接池隔離
- 排隊無上限，隊列堆積把下游壓死
- 超時只配一個地方，鏈路仍然會“無限等待”
- 熔斷后沒降級，用戶體驗直接崩盤
- 線程池參數拍腦袋，沒壓測沒校準
- 重試無退避，失敗時把流量放大
- 緩存 miss 沒兜底，熱點直接打穿 DB
- 沒有監控閉環：你根本不知道隔離有沒有生效
05 落地順序：先做哪 3 個最值？（1–3 年后端照著做）
如果你資源有限，建議按這個順序落地（投入產出比最高）：
第一優先級（立刻能救命）
- 全鏈路超時（至少：入口/服務內調用/下游依賴）
- 核心接口限流（保護線程池與 DB）
- 弱依賴熔斷 + 降級兜底
第二優先級（提升抗壓上限）
- 線程池隔離：核心/非核心分池
- 可異步的全部隊列化（并補齊堆積告警）
第三優先級（體系化治理）
- 業務分級與開關化降級
- 數據層分倉/保護閾值、熱點治理
06 無狀態自查：你的服務到底能不能水平擴？
快速自查清單（任意命中一條，就要警惕）：
- 是否把請求態數據放在本地內存/靜態變量（重啟/擴容就丟）
- 是否依賴本地文件作為狀態（多實例一致性難保證）
- 是否把“本地緩存”當唯一來源（多實例數據漂移）
- 是否依賴單機定時任務保證一致性（擴容后重復執行/漏執行）
改造方向：
把狀態下沉到 Redis/DB/消息系統，并補齊冪等；服務實例盡量做到“可隨時替換”。
07 監控指標清單：怎么判斷隔離真的生效？（閉環）
建議至少看這 8 類：
- 流量：QPS、突增速率
- 延遲：P95/P99、超時數
- 錯誤：5xx、依賴錯誤率
- 線程池：活躍線程數、隊列長度、拒絕次數
- 連接池：占用率、等待時間
- DB：慢查詢數、CPU/IO、鎖等待
- 緩存：命中率、熱點 key、回源量
- 降級/熔斷：觸發次數、恢復次數、受影響接口
新聞搜索
