那天發生了什麼
我在跑一場近百人的線上課，每個人打開電腦加手機，系統顯示同一時間有 140 個裝置在使用網站。
我心裡想應該還好。
不久後訊息一連跳出來：
- 老師，我 AI 這邊顯示 CSRF 打不開
- 老師，是不是當機了
- 老師，我手機也載不進來
那一刻不是某個人連不上，是整個網站在我學員眼前慢慢倒下。
其實是三件事一起發生
我把後台記錄翻一翻，發現是三個問題撞在一起。
一、140 個裝置同時操作，把系統壓垮
平常我的系統同時線上使用者是 30 到 50 個人。那一刻衝到 140 以上，而且同時要求 AI 運作。
平常的數據完全推不出來高峰時長什麼樣。
更糟的是，系統一邊處理不來，一邊還默默自動重試。每一次失敗都會自己再做三次，所有共用底層的網站一個一個跟著倒。
二、資料庫被同時讀爆
我用的方案平常完全夠用，但這次太多人同時抓資料，直接讓資料庫崩了。
主因是我自己的寫法問題：進到首頁就會即時抓取，跑完 AI 還要再存檔讀取。太多人進來導致持續抓取，跑到上限。
問題不在資料庫不夠強，是我的程式每個動作都打它一次。
140 人 × 平均每人 5 次動作 ＝ 700 次抓取湧進來
寫程式的時候我以為反正會快取，結果完全沒有快取。
三、AI 的 API 同時太多人打
第三個我事後才意識到：我所有 AI 工具背後都是同一支 API key。
平常每分鐘大概 5 到 10 次請求，那 30 分鐘衝到 200 次以上。供應商那邊有每分鐘請求數限制，一過上限就直接擋。
於是學員看到的是「AI 服務忙碌中，請稍後再試」。不是 AI 壞了，是我被擋下來了。
當下我做了什麼
跟學員說不好意思我處理一下，然後先做兩件事：
- 把每次都要建新連線的地方，改成只開一條共用
- 把每次都要重新驗證的動作，改成 60 秒只驗證一次
光這兩個改動，系統負擔就少了一半以上。
然後加 4GB 的緩衝記憶體讓伺服器有呼吸空間，最後服務一個一個回來。
三層對應三個問題
| 問題 | 修法 |
|---|---|
| 流量壓垮 | 加共用連線與驗證快取；首頁資料加 60 秒快取，重複進首頁不打資料庫；任何活動超過 50 人一定先做壓力測試 |
| 資料庫爆掉 | 每個查詢前先想這個結果可以快取多久；不是即時的資料就快取，不要每次都查；高頻查詢走快取不走資料庫 |
| API 限流 | 加排隊機制，一次只放幾個請求進去；多支 key 輪替，不要把所有工具壓在一支；一樣的提示詞加快取；用量到 80% 自動通知 |
我學到三件事
一、課前要先壓力測試
以前我覺得應該還好。現在我學到：任何活動超過 50 人一定要先模擬一次。
50 人乘以 2 個裝置等於 100 個連線，已經是平常的數倍。
二、共用是雙面刃
我所有產品都共用同一個後端加同一支 API key。省成本沒錯，但只要其中一個出事，全部一起倒。
下一步是不同產品分開，至少分兩個資料庫加多支 key。
三、留呼吸空間給系統
伺服器、資料庫、API 用量平常都夠用，但一次活動就會塞滿。
真正讓我反省的事
寫到這裡我才發現，我當時同時上線八個專案，我以為我做了八個獨立產品。
實際上我做了一個共用底層加八個前端。當底層出事，八個全死。
未來要做大，不是再多開幾個產品，是要把底層分開。
那你呢？你用 AI 做的系統，多人用的時候撐得住嗎？
你今天可以做的三件事
- 任何活動超過 50 人，先做一次模擬測試，看你的系統撐到第幾個
- 列出你所有產品，看有沒有共用同一個後端或 API key
- 寫一個掛掉會自動通知你的機制，不要等用戶告訴你
這篇整理自我 2026 年 6 月 28 日 發在個人臉書的貼文（當時觸及 2,840、收藏 11、分享 9）。原文較口語，這裡補上結構與表格，方便收藏後回頭查。
看臉書原文與留言討論