高併發壓力來襲，你的服務是彈性伸縮，還是直接斷線？

一、從「搶換美元導致網銀當機」談起

近期由於美元匯率大幅下跌，台幣強勢升值，引發民眾搶著把台幣兌換成美元。這一波突如其來的熱潮，造成多家銀行網路銀行大當機——登入失敗、交易卡住、網頁打不開，一度讓使用者氣憤，也讓銀行客服電話被打爆。

這不是第一次發生類似事件。

每次遇到搶票、搶購秒殺商品、補助申請開放時，各種系統癱瘓的新聞就層出不窮。這些現象背後，其實反映的都是同一個問題：高併發壓力。

為什麼現代系統仍會怕「人一多」？不是用了雲端、容器、CDN 就能撐住一切了嗎？本篇文章，就要透過這次的網銀事件，來聊聊「高併發架構設計」背後的關鍵思維與誤解。

二、什麼是高併發？為何它會讓服務崩潰？

高併發，指的是「在極短時間內，有大量使用者同時發送請求給系統」。這些請求可能是：查詢匯率、登入帳號、送出換匯指令，或是下載報表……當這些操作集中在同一時間內湧入，系統資源一下就被吃光了。

舉個簡單比喻：

想像你家巷口早餐店，一次最多接 5 個人的單。結果今天突然湧入 100 人同時排隊，結局會是什麼？

• 櫃檯收單速度變慢（API Gateway 壓力大）
• 廚房處理不過來（資料庫或後端服務卡住）
• 排隊的人開始吵架（使用者體驗變差）
• 最後有人氣到離開，或轉去競爭對手那吃早餐（流失客戶）

科技服務也是一樣的。並不是系統寫得不好，而是沒有針對「瞬間大量流量」做足夠準備。

那為什麼大家不一開始就設計得超強、超快？

因為資源是錢。你不會為了 365 天裡的 1 天高峰，花 365 倍的資源去撐住每一天。

這就需要一種能力：「彈性伸縮」。

三、彈性伸縮的系統，長什麼樣？

一個能應對高併發壓力的系統，通常會有以下幾個設計特徵：

（1）前端快取與 CDN

• 將熱門但變化不大的內容（如匯率列表、常見問題）緩存在 CDN 中。
• 使用者每次點進網銀首頁，不用都打到核心伺服器，減少壓力。

（2）API Gateway 與請求速率限制（Rate Limiting）

• 把所有 API 請求都經過一層總閘門。
• 例如每個帳號每秒最多只能查一次匯率，防止濫用或誤觸連打。

（3）非同步處理與排隊機制（Queue）

• 把非即時處理的請求（例如換匯後通知 Email）丟進佇列慢慢處理。
• 使用 Kafka、RabbitMQ 等訊息中介軟體，削峰填谷。

（4）快取資料庫查詢結果

• 熱門帳號資訊、匯率數據存在 Redis、Memcached 之類的快取層。
• 讓 1 萬人查詢時，只會查一次 DB，其餘都從記憶體中取出。

（5）資料庫讀寫分離、分庫分表

• 查詢請求由「從庫」處理，寫入請求才打「主庫」。
• 如果資料表太大，切成幾個表（例如依使用者 ID 分區）加速存取。

（6）雲端原生部署 + Auto Scaling

• 搭配 Kubernetes 等平台，讓系統能根據壓力自動擴充服務實例。
• 高峰期間自動加節點，離峰自動回收，節省成本。

總結來說，這些設計的核心目標就是：在突發流量進來時，系統能自動放大自己，不被打垮；在流量退去時，也不浪費資源。

四、常見誤區：你以為能撐，其實撐不了

 誤區一：用了雲端就等於能撐高併發

雲端只是資源池，不代表會自動幫你撐。沒有設好自動擴充策略（Auto Scaling Policy），雲端也是紙老虎。

 誤區二：加機器就好，DB 跟得上嗎？

就算你能快速擴充 10 倍伺服器，但如果資料庫查詢仍是單點、沒索引、沒拆分，那 10 倍的請求只會讓它更快死。

 誤區三：等高併發來了再調整就好

流量暴衝往往是「毫無預警」。臨時加快篩選條件、手動擴機器，早就來不及了。這是「架構」問題，不是「應變」可以解的。

五、從壓力中看見韌性：高併發是企業信任的斷點測試

這次搶換美元引發的當機事件，對銀行來說是壓力測試，對使用者來說則是信任考驗。使用者真正信任的，是這套系統在關鍵時刻是否穩定可靠、不中斷。

這不只是一場金融事件，而是一個提醒——再華麗的功能、再炫的 UI，在系統撐不住的那一刻，全部都等於零。

高併發架構不只是科技團隊的事，它代表了整個企業的數位體質。

與其說這是 IT 的問題，不如說這是經營信任的基本功。

高併發，是服務能否被信賴的試金石

每一次突如其來的高流量事件，不只是對系統的挑戰，更是檢驗服務是否夠穩的時刻。做得再多、功能再強，系統一旦斷線，使用者的信任也會跟著斷。

高併發不該被視為例外情況，而應成為常態下的基本考量。能否撐得住暴衝流量，決定了服務是否值得依賴。