高流量網站怎麼撐？以運動數據平台為例的架構判斷

「平常都好好的，一到活動就掛。」

很多經營網站或平台的老闆都講過這句話。可能是電商的限時搶購、售票開賣、直播導購，也可能是運動賽事。比賽開打前十分鐘，網站開始變慢；關鍵比分出現的那一刻，所有人同時重新整理，頁面開始轉圈，接著出現錯誤畫面。老闆在群組裡問是不是被攻擊了，工程師回：不是，是人太多。

我是熊董，川輝科技創辦人。帶團隊做系統導入七年，經手超過 34 個案子、14 個以上產業，現在一個人加 AI，一年交付 2,000 萬以上的客製系統。這篇我用運動數據平台當例子，不是要講某個客戶的故事，而是因為它把高流量網站的難處放到最大：高峰集中、資料要即時、每個人都在看同一份東西。把它想通了，其他有活動高峰的網站，道理都一樣。

高併發網站撐不撐得住，關鍵通常不在主機買多大台，而在你有沒有讓大部分的請求根本不用碰到資料庫。運動數據平台這類網站有三個特性：讀遠多於寫、高峰時間大多可以預期、同一份資料同時被很多人看。順著這三個特性設計，能快取的全部快取、寫入和讀取分開走、高峰前先擴容、真的撐不住時先關掉非必要功能，比出事後再加主機有效得多。老闆不需要懂技術細節，但要在上線前問廠商幾個關鍵問題，並要求一次照真實高峰情境做的壓力測試。

一到高峰就掛，是主機不夠大嗎？

先講老闆的直覺：網站撐不住，就加主機。這個想法不是錯的，在很多情況下也確實有效。雲端主機可以隨時調大，花錢就能換到效能，這是最快的止血方式。

但很多時候，你會發現主機加了一倍，網站還是在同一個時間點掛掉。原因在於瓶頸不在主機，而在後面那個大家共用的東西，通常是資料庫。

想像一下：一萬個人同時打開比賽頁面，每個人的請求都跑去資料庫問一次「現在比分多少、誰得分、技術統計是什麼」。資料庫要在同一秒回答一萬次幾乎一樣的問題。你在前面加再多台網頁主機，只是讓更多請求更快地湧進資料庫，它反而更早被壓垮。

這就像一間只有一個收銀台的店，你在門口多開了十個入口，客人進來得更快，但結帳的隊伍只會更長。真正的解法不是開更多入口，而是讓大部分的客人根本不用排那個收銀台。

先搞清楚你的流量長什麼樣子

在談任何技術之前，要先回答一個問題：你的流量長什麼樣子？

運動數據平台的流量有三個很明顯的特性：

• 讀遠多於寫：比分、賽程、球員數據，一份資料被寫進去一次，卻被成千上萬人讀取。
• 高峰可以預期：比賽幾點開打，賽程表上都寫著，高峰幾乎不會突然出現。
• 大家看的是同一份東西：同一場比賽的頁面，每個人看到的內容幾乎一模一樣。

這三個特性，決定了該怎麼設計。用一個假設來感受一下規模：假設平常同時在線的人大約 500 人，熱門比賽開打前，同時在線可能暴增到平常的二十倍，也就是一萬人；如果頁面設計成每十秒自動更新一次，那就是每秒一千次請求，全部集中在同一場比賽。只要每一次請求都要查資料庫，資料庫就要每秒處理一千次一模一樣的查詢。

這個數字是假設的，你的網站可能大很多，也可能小很多。重要的不是數字，而是分清楚兩件事：平均流量跟高峰流量差幾倍，以及高峰的時候大家在看什麼。很多中小企業的網站其實沒有高峰問題，平均和高峰差不了多少，那就不需要這篇講的大部分做法，一般的架構加上適當的主機就夠了。不要為了一個不存在的問題花錢。

用這張圖對一下你的網站落在哪一格。高峰大但資料不需要即時的，例如活動介紹頁、賽程表，最好處理，整頁快取起來就好。高峰大又要即時的，像比賽進行中的比分頁，是最難的一格，也是這篇主要在講的。高峰不明顯的，一般架構就夠；高峰不明顯但資料要即時的，重點放在資料庫查詢本身的效率。

讓請求不碰資料庫：快取要做三層

快取的意思很簡單：把算好的結果先存起來，下一個人來問同樣的問題時，直接給他存好的答案，不用再問資料庫一次。

在高流量網站裡，快取通常做三層：

第一層，內容傳遞網路。圖片、樣式檔、程式檔、不常變的頁面，放在分散各地的節點上，使用者從離他最近的節點拿，根本不會進到你的主機。這一層可以擋掉大部分的流量。

第二層，頁面或 API 的短時間快取。很多人以為即時資料不能快取，其實可以。比分頁面快取一到三秒，對使用者來說幾乎感覺不到差別，但對主機來說，原本一秒一千次的查詢，變成一秒只要查一次，其他九百九十九次直接拿快取。即時跟快取不是對立的，關鍵是快取多久。

第三層，資料快取。把常用的資料放在記憶體型的快取服務裡，例如排行榜、球員基本資料，需要時從記憶體拿，比查資料庫快很多。

另外一個常見的做法是改變更新方式。與其讓每個人的瀏覽器每十秒來問一次「有沒有新比分」，不如反過來，有新比分時由伺服器主動推給大家。這種推播的方式，在沒有新資料的時候幾乎不產生請求，高峰時對主機的壓力小很多。

寫入和讀取，要分開走

第二個原則是讀寫分離。

在運動數據平台裡，資料是怎麼進來的？通常是從數據來源接到一筆新的比分或事件，寫進資料庫。這件事一場比賽可能發生幾百次。而讀取這份資料的，是幾千、幾萬個使用者。

如果寫入和讀取用同一條路，那每次有新資料寫入，都要跟幾萬個讀取請求搶同一個資料庫。比較好的設計是：新資料進來時，先寫入一次，然後馬上把「大家要看的結果」算好，例如這場比賽的最新比分、技術統計、排行榜，放進快取。使用者讀取的時候，拿的都是已經算好的結果，完全不用碰到寫入的那條路。

同樣的道理，像排行榜、累積統計這類計算量大的東西，不要等使用者打開頁面才算，而是在資料更新時就先算好。使用者等的時間越短，主機的負擔也越小。

如果寫入本身也很多，例如很多使用者同時留言、投票、預測，那就再加一個排隊的機制：寫入的請求先放進佇列，由後端依序處理，不要讓高峰時的瞬間寫入直接打在資料庫上。

高峰前先擴容，撐不住時優雅降級

運動數據平台有一個很大的優勢：高峰時間是知道的。賽程表上寫著幾點開打，你就可以在開打前先把主機和快取的容量調高，比賽結束後再調回來。比起等流量來了才自動擴容，提前擴容反應更快，也比較不會在擴容的那幾分鐘裡出事。

但不管準備得多充分，總有估錯的時候。所以第二件事是事先設計好「撐不住的時候要先放棄什麼」。這叫降級設計，概念是保住核心功能，先關掉其他的。

以比賽頁面為例，核心是比分和賽況。留言區、個人化推薦、相關文章、廣告輪播，這些在高峰時都可以先暫停或換成簡化版。事先在系統裡做好開關，高峰時一鍵切換，使用者至少還看得到比分，而不是整頁都打不開。

如果流量真的大到核心功能也撐不住，還有最後一道防線：排隊頁。先讓一部分使用者進來，其他人看到一個「目前人數眾多，請稍候」的頁面。體驗不完美，但總比所有人一起看到錯誤畫面好。

上線前，老闆該問廠商的五個問題

老闆不需要懂快取怎麼設定，但上線前一定要問清楚下面這幾件事。答不出來或答得很模糊的，就是風險所在。

要問的問題	為什麼要問	好的回答大概長這樣
高峰時有多少比例的請求不會碰到資料庫？	決定能撐多大的流量	說得出哪些頁面有快取、快取多久
壓力測試是用什麼情境、多少人做的？	確認測試貼近真實高峰	依過去或預估的高峰人數，模擬同時操作
撐不住的時候，會先關掉哪些功能？	確認有降級設計	有清楚的開關清單，知道誰來切
高峰前要怎麼擴容、誰負責？	避免擴容靠臨時起意	有排程或流程，知道比賽前多久調整
出事時怎麼知道、多久內會有人處理？	確認有監控與值班	有即時監控與警示，高峰時段有人待命

這五個問題裡，我最看重的是第二個。很多壓力測試是用「平均流量」或「一個方便的數字」測的，測完報告很漂亮，但跟真實高峰差了好幾倍。測試的情境要盡量貼近真實：多少人、同時做什麼、在多短的時間內湧進來。測試也最好在上線前做一次、在大型活動前再做一次。

這類規格最好在簽約前就寫進需求，而不是上線後才補。系統開發時規格怎麼寫、驗收怎麼定，我在客製化系統開發要注意什麼那篇講得比較完整；如果你正在找開發團隊，系統開發外包怎麼找有篩選廠商的方法。

影音平台也是流量集中的一種網站。我們接手過一個影音（OTT）平台，前一家廠商交付不了，接手後三個月做完 18 項功能。接手別人做不完的系統時，我常看到同一件事：一開始沒有人把極端情況講清楚，例如高峰會有多少人、同時在做什麼，架構就照一般網站的方式蓋下去，之後每加一個功能都在補洞。接手的過程可以看影音平台開發那篇。

常見問題

高併發網站一定要用雲端主機嗎？

不一定，但雲端在高峰明顯的網站上很有優勢，因為容量可以依需求調整，高峰前調高、結束後調回，不用為了一年幾次的高峰長期養大主機。如果你的流量很平穩，固定規格的主機反而可能比較好管理。

即時資料也可以做快取嗎？

可以，關鍵是快取多久。比分這類資料快取一到三秒，使用者幾乎感覺不到，但主機的查詢次數可以大幅減少。真正要求每一毫秒都即時的情境，可以改用伺服器主動推播新資料，而不是讓每個人不斷來詢問。

網站被大量流量擠爆，跟被攻擊有什麼不同？

結果看起來很像，都是網站變慢或打不開，但來源不同。正常高峰來自真實使用者，時間通常可以預期；攻擊則是刻意製造的大量請求，常在非預期時間出現。兩者的防護都要做，前者靠快取與擴容，後者靠防火牆與流量過濾服務。

中小企業的網站需要考慮高併發嗎？

多數不需要。先看平均流量和高峰流量差幾倍，如果差距不大、也沒有固定的活動高峰，一般架構加上適當的主機就夠了。有限時搶購、售票、直播導購或賽事這類集中高峰的網站，才需要在規劃時就把高併發設計進去。

撐住高峰的關鍵，是讓大部分請求不用排隊

一句話收尾：高流量網站要撐住，靠的不是買更大的主機，而是讓大部分的人根本不用去排資料庫那個收銀台，再為真的撐不住的那一刻準備好退路。

如果你的網站或平台一到活動就出狀況，但說不清是架構、主機還是程式的問題，可以帶著最近一次出事的時間點和情境來，我們用 30 分鐘免費診斷先判斷問題大概在哪一層。