1. 題目
一個非同步訂單處理服務在尖峰期出現延遲上升。監控顯示穩定吞吐約 200 req/s，端到端平均延遲約 150 ms。請用 Little 定律估算在途請求數，解釋延遲、吞吐與佇列的關係，並給出避免 backlog 失控的工程動作。
2. 約束與澄清
- Little 定律描述穩定系統的長期平均關係：
L = λW，其中 L 是系統內平均請求數，λ 是平均吞吐，W 是平均停留時間。 - 先說明統計視窗、請求邊界與單位；短暫突發或尚未穩定的系統不能直接套用長期平均。
- 要區分服務時間、排隊時間與端到端停留時間，否則會低估並發或誤配執行緒池。
- 還要確認容量上限、逾時策略、優先級與可丟棄工作。
3. 核心推導
把 200 req/s 與 0.15 s 相乘，得到平均在途請求數 L = 30。這不是「最多只能有 30 個請求」，也不是 p99 並發；它是給定視窗下的平均庫存。若吞吐不變而平均停留時間翻倍，平均在途請求也翻倍，通常表示佇列或依賴延遲正在成長。
4. 參考分析
text
lambda = 200 # requests / second
W = 0.150 # seconds / request
L = lambda * W # 30 requests in the system on average
if arrival_rate > sustainable_service_rate:
queue grows without a stable bound
apply_admission_control_or_scale_out()
capacity = concurrency_limit / target_latency工程上應分別測量進入佇列、開始處理、完成處理的時間。使用 Little 定律可反推容量：當並發上限為 100、目標平均停留時間為 200 ms 時，穩定吞吐的粗略上限約為 500 req/s；實際還要留出尾延遲、突發與依賴抖動餘量。
5. 過載場景與取捨
當到達率持續高於可服務率，佇列會增長，W 變大，進而讓 L 變大，形成逾時與重試放大的回饋迴路。無限佇列只把失敗延後，工作完成時可能已失去價值。可採用有界佇列、快速失敗、優先級、負載削減、背壓或擴容；每種策略都要明確丟棄哪類工作以及如何向呼叫方回報。
6. 驗證與觀測
- 按時間視窗記錄到達率、完成率、在途數、平均與 p95/p99 延遲。
- 用
L、λ、W三組獨立指標互相校驗，發現單位或取樣邊界錯誤。 - 進行受控壓測，逐步提高到達率，觀察佇列長度、逾時率與恢復時間。
- 為佇列深度、年齡、並發上限、拒絕率與重試率設定告警，並驗證擴容或降載後的回落速度。
7. 常見誤區
- 把平均 L 當作硬並發上限，忽略突發、尾延遲與排隊分布。
- 用服務處理時間代替端到端 W，漏掉網路、鎖與依賴等待。
- 在未達到穩定狀態時用一小段樣本推斷長期容量。
- 只擴容消費者，不限制生產者，結果讓共享依賴或下游佇列繼續過載。
8. 面試評分點
能正確代入公式
應統一單位，算出 200 × 0.15 = 30，並解釋這是平均在途請求數而非上限。
能劃分時間邊界
應區分排隊、服務與端到端時間，說明取樣視窗與穩定狀態假設。
能識別過載回饋
應說明到達率超過服務率會讓佇列、延遲、重試與並發相互放大，並提出有界化措施。
能用資料驗證容量
應結合壓測、p95/p99、佇列年齡、拒絕率與恢復時間驗證結論，而非只報一個平均數。