為什麼 Steam 伺服器在大型促銷期間經常當機

Steam 伺服器在大型促銷期間經常當機，是因為海量並發使用者的突然湧入，壓垮了原本按日常平均負載而非尖峰需求來建置的基礎設施。導致這一現象的核心有四個因素：流量激增、容量上限、擴容遲緩，以及資料庫或身分驗證瓶頸。你可以把它想像成一條按平日通勤流量設計的高速公路。平常的週二，它運作良好；可一到節假日車流湧來，所有車道就會同時壅塞。道路本身並沒有變化，變化的是車流規模。這裡也是同樣的道理：在可預見的購物高峰來臨時，原本為平靜時段最佳化的系統會突然承受巨大衝擊，而最脆弱的共享元件往往最先失守。

核心要點

大型促銷會帶來巨大的流量高峰，壓垮原本按日常正常流量設計的伺服器。
Steam 的架構是圍繞平均負載而不是尖峰需求設計的，因此資料庫和登入服務等共享系統很容易成為瓶頸。
單純增加伺服器並不是簡單有效的解決方案，因為擴容既緩慢又昂貴，而真正的壓力往往集中在共享後端系統上。
Steam 會使用排隊、限流和分階段發布等手段來緩解高峰衝擊，但這些措施只能減輕當機程度，無法徹底避免故障。
理解這些限制後，你就會明白：伺服器當機其實是為了保證日常高效運作而做出的一種可預見權衡。

促銷流量高峰解析

並發使用者如何激增

季節性促銷就像按下了一個開關。數以百萬計的使用者會在極短時間內同時開啟商店用戶端。社群使用者常把這一時刻形容為「本質上是被使用者 DDoS 了」。這種說法很貼切。分散式阻斷服務攻擊會用大量無效請求淹沒目標；而促銷則會用大量真實買家淹沒同一目標。對伺服器來說，這兩種模式造成的結果是一樣的：湧入的連線數超過了入口所能承受的極限。

夏季促銷和聖誕促銷之類的活動，就是這種現象週期性出現的觸發點。所有人都提前知道日期，願望清單早已準備好，付款卡也已經待命。結果形成的不是逐步增長的流量，而是一場同步發生的搶購潮。你可以想像那條負載曲線：一年中的大部分時間都較為平穩，而到了促銷首日，它幾乎是垂直飆升。

為什麼可預見的高峰仍會壓垮系統

你也許會認為，既然活動時間早已確定，規劃起來應該並不困難。畢竟行事曆給了工程師數週的準備時間。但「能預測」並不等於「能防住」。高峰到來的速度，遠快於任何漸進式爬升；而它又會同時衝擊許多其他服務共同依賴的共享系統。

需求還會集中爆發在特定環節。商店頁面、結帳流程和登入系統往往會同時承壓。某一個環節的激增，往往又會拖累其他環節。可預見的時間節點，只能讓你知道問題何時開始，卻無法減少湧來的人群。正是這種「知道會出事」和「真的扛得住」之間的差距，解釋了為什麼幾乎每次大型促銷都會重演同樣的局面。

為什麼 Steam 伺服器經常當機

按平均負載建置的架構

Steam 的基礎設施是按典型日常流量來配置的，而不是按一年中最繁忙那個小時來設計的。工程師在規劃容量時，會以正常流量為基準。這裡的正常流量包括瀏覽、下載，以及任何一個普通週二都會持續發生的零星購買。在這種負載下，系統運作得相當從容，甚至還保留一定餘量。

而大型促銷會打破這種前提。平時只需要服務適度人群的同一套伺服器，會突然面對數倍於平常的大規模使用者。每一個元件都有它的承載上限：前端 Web 伺服器只能接受有限數量的連線，應用程式伺服器每秒只能處理有限數量的請求，資料庫叢集一次也只能承受有限的查詢量。一旦需求突破這些上限，請求就會開始排隊、逾時，最終直接失敗。

這正是 Steam 伺服器在大型促銷期間頻繁當機的原因。並不是硬體壞了，而是整個設計預設了一個促銷永遠不會遵守的負載前提。你可以把它想像成一家只有 50 個座位的餐廳，卻在同一個晚上突然接到 500 個訂位。廚房、服務員和門口接待會在同一時間全部達到極限。

過度預留容量的成本

接下來一個很自然的問題是：為什麼不直接增加更多伺服器？社群中的普遍看法是，這並不能真正解決問題。額外機器只有在瓶頸出現在運算資源時才有幫助。而在促銷期間，真正承壓的是身分驗證和資料庫這類共享系統。你在前面加更多 Web 伺服器，只會把更多請求導向同一條已經緊繃的窄管道。

成本同樣是關鍵因素。若要按尖峰需求建置容量，就意味著一年中大部分時間都要為閒置資源持續付費。對於一個絕大多數時間只承受中等負載的平台來說，很難合理化那些長期閒置數月的硬體成本。過度預留還會提高維運複雜度：機器越多，協調越複雜，設定越繁瑣，出問題的環節也越多。

最終的現實結果，是一種有意為之的權衡。Steam 會按更符合實際的日常流量來配置整體伺服器規模，並接受極端高峰必然會帶來壓力這一事實。這樣的選擇讓平台在平時保持了合理成本；但與此同時，也幾乎註定了 Steam 伺服器在促銷到來時會頻繁當機，因為平均負載與尖峰負載之間的差距，單靠預留一些額外硬體根本無法填平。

擴容難題

為什麼伺服器無法瞬間擴出來

很多人會把雲端容量想像成一個旋鈕：把它轉大，新機器立刻出現。現實並沒有這麼快。一個新執行個體需要完成資源分配、設定部署，並接入網路體系。每一步都需要時間，而促銷洪峰往往在幾分鐘內就會到來。

預熱過程還會帶來進一步延遲。新機器一開始是「冷」的，它需要載入應用程式碼、建立連線、填充快取，之後才能高效地服務請求。如果把這種延遲放大到數百個執行個體，等待擴容生效的同時，請求佇列往往已經越積越長。自動化當然能提供幫助，但每個新節點在接收流量之前，仍然必須先通過健康檢查。這也是為什麼 Steam 伺服器經常會在促銷初期最容易當機——因為擴容速度趕不上流量暴漲的速度。

高壓下的負載平衡

負載平衡器的職責，是把進入系統的請求分散到整個平台中的各台伺服器上。正常情況下，這項任務相對簡單；而到了促銷期間，負載平衡器本身就可能成為瓶頸。因為所有請求都必須先經過它，它就必須獨自扛住最前端的全部洪峰。

而且流量分配也未必始終均勻。有些請求比其他請求更「重」，一台伺服器過載後，負載平衡器在重試失敗連線時，反而可能把鄰近伺服器一併拖垮。重試機制不會減輕壓力，反而會放大流量。工程師會藉助健康檢查和流量整形來應對，但這些工具本質上只是爭取時間，並不能提供無限的備援空間。

資料庫與登入瓶頸

極端負載下的共享系統

每一次商店頁面存取、購物車更新和購買行為，最終都會流向一小組共享後端系統。資料庫叢集和身分驗證服務位於這個網路的核心位置。它們同時服務所有訪客，而且無法為每一位買家各自拆分出一套獨立副本。

這種共享設計天然會形成單點壓力。一場促銷會在短時間內把數百萬次讀寫查詢同時壓到同一個資料庫上。鎖開始形成，查詢開始等待，回應時間不斷上升。平安夜那次故障就把這一點表現得很清楚：網站和商店頁面幾乎在同一時間一起失靈，因為它們依賴的是同一套底層系統。一個元件承壓過大，就能把其他部分一起拖下水。

登入排隊與工作階段失敗

身分驗證本身也會帶來額外壓力。每位買家在購買前都需要先登入，而每一次登入都會生成一個系統必須維護的工作階段。高峰時段一來，工作階段儲存很快被塞滿，新的登入請求就開始失敗。於是你會看到那些經典症狀：轉個不停的載入動畫、錯誤頁面，以及莫名其妙被清空的購物車。

這種超載模式並不只發生在促銷期間，熱門遊戲發售時也會重演同樣的局面。以《空洞騎士：絲之歌》發售時為例，玩家會同時湧向商店和下載服務，相同的瓶頸再次出現。這個類比很重要，因為它說明，真正的薄弱點並不是促銷本身，而是共享的登入層和資料庫層。這也正是為什麼 Steam 伺服器會在所有「同步需求爆發」的時刻頻繁當機——無論驅動這波流量的是打折活動，還是熱門新作上線。

Steam 如何緩解這場衝擊

排隊、限流與分階段發布

在流量洪峰來臨時，Steam 並不是毫無作為。工程師會部署一整套控制手段來放慢衝擊、拉長流量曲線。排隊機制是第一道防線。當需求超過某個閾值時，系統會把使用者放進等待佇列，而不是直接拒絕存取。你會看到自己的排隊位置和預估等待時間。等待固然讓人煩躁，但它能避免後端在瞬時並發請求牆面前徹底崩潰。

限流機制則提供第二層防護。平台會限制單一用戶端或單條連線在一定時間視窗內能送出的請求數量。機器人和激進腳本通常會很快撞上這個上限，而普通買家往往不容易察覺。分階段發布則補上最後一環：工程師會分批啟用新增容量，並在每一步觀察系統表現，再決定是否開放下一步。這種做法有助於在促銷最危險的幾個小時內保護整體可用性。

為什麼緩解措施也有極限

這些工具確實能爭取時間，但時間本身也有代價。排隊機制只有在後端最終確實能處理完等待人群時才有意義。如果資料庫一直處於飽和狀態，隊伍只會越排越長，而不會真正縮短。限流同樣是一把雙面刃：設得太嚴，正常買家也會和機器人一起被擋在外面。

分階段發布也有它自己的延遲。每一個階段都需要先完成監控和驗證，之後才能進入下一階段，而促銷高峰持續的是幾個小時，不是幾天。貫穿這一切的硬上限，仍然是共享的登入層和資料庫層。排隊和限流都無法真正修復一個已經過載的中央系統。它們可以減輕當機的衝擊，卻無法消除尖峰需求與有限共享容量之間的根本錯配。

現在，你已經看到了完整圖景：促銷流量高峰超出承載能力，系統架構按平均負載設計，動態擴容既慢又貴，而共享的資料庫與身分驗證系統最終形成瓶頸。這就是為什麼 Steam 伺服器在大型促銷期間經常當機：極端需求撞上有限且共享的基礎設施，最脆弱的一環便會率先失守。工程師當然會持續改進排隊、限流和分階段發布機制，以保護整體可用性。這些努力能讓每一次高峰變得稍微平緩一些，但節日級人潮與日常級系統之間的根本不匹配，依舊是一個可以預見、也難以徹底消除的挑戰。