技術名詞

Session、Cache、Queue 是什麼?網站「又快又穩」背後的三個後端名詞,用餐廳和寄物櫃講給老闆聽

2026.07.28 · 92 次瀏覽
Session、Cache、Queue 是什麼?網站「又快又穩」背後的三個後端名詞,用餐廳和寄物櫃講給老闆聽

用寄物櫃號碼牌、便利商店貨架與餐廳候位,講清楚讓網站在尖峰不當機的三根柱子

分享:

老闆在報價單上看到三個詞:「改用 Redis 存 Session、加開 Cache 快取、導入 Queue 佇列」,加起來一筆不小的費用,卻不敢問「這到底是什麼、為什麼要花這個錢」。這三個詞常一起出現,因為它們共同決定一件事:你的網站在「人一多」的時候,到底是又快又穩,還是又慢又當。這篇用寄物櫃、便利商店和餐廳候位,把 Session、Cache、Queue 一次講清楚。

Session(會話):伺服器記得「你是誰」的暫時記憶

一句話:Session 是伺服器暫時記住「你是誰、你剛做了什麼」的記憶。

類比:飯店寄物櫃的號碼牌。你寄了東西拿到一張號碼牌,之後只要出示號碼牌,櫃檯就知道哪個櫃子是你的——你不用每次都重報姓名。Session 就是那張號碼牌:你登入一次,伺服器發給你一個識別碼,之後每頁都認得你。

實際例子:補習班家長登入後台看孩子的成績,登入後不用每點一頁就重新輸入帳密,靠的就是 Session。而 Session「存在哪裡」很關鍵:存在單台伺服器的硬碟上,一旦你的網站擴充到多台伺服器(分流),家長可能在 A 機登入、請求被導到 B 機就被登出。把 Session 集中存到 Redis 這類共用記憶體,多台機器才能共用同一張「號碼牌」。

Cache(快取):把常用結果先算好放旁邊

一句話:Cache 是把常被查詢的結果先算好、放在拿得快的地方,下次直接給,不用重算。

類比:便利商店把熱賣商品放在門口。店員知道大家都買同一款咖啡,就先擺在最好拿的地方,不用每次都跑到後面倉庫。Cache 就是網站的「門口貨架」,把熱門頁面或查詢結果先備好。

實際例子:餐廳官網的菜單頁如果每次都去資料庫撈一次,尖峰時段每個客人都慢半拍;把菜單結果快取起來,第二個客人之後幾乎是秒開。快取直接影響頁面載入速度(LCP)與伺服器負擔——同一台機器能扛的人瞬間變多。代價是「資料更新後要記得清快取」,否則客人看到舊菜單。

Queue(佇列):把不急的工作排隊,稍後處理

一句話:Queue 是把「不用馬上完成」的工作排成一列,讓系統稍後在背景慢慢做。

類比:餐廳的候位叫號機。客人抽號碼、去旁邊等,餐廳照順序叫號,不會讓所有人擠在門口。Queue 就是把工作抽號排隊,背景依序處理,不卡住前台。

實際例子:電商客人下單後要寄「訂單確認信」,如果讓客人在結帳頁乾等信寄完才顯示成功,體驗很差;把「寄信」丟進 Queue,畫面立刻回覆「下單成功」,信在背景寄。大量簡訊、產報表、圖片轉檔、串接第三方 API,都靠 Queue 才不會在尖峰把網站拖垮。

三者怎麼串在一起(概念圖)

想像一個使用者請求進來的動線: 先用 Session 認出「這是誰、有沒有登入」; 再問 Cache「這個頁面/資料有沒有現成的,能不能秒回」; 遇到「寄信、轉檔、跑報表」這類慢工,就丟進 Queue 背景做、先把畫面還給使用者。三者合起來,網站就能同時做到「記得你(Session)、給得快(Cache)、扛得住尖峰(Queue)」——這正是「又快又穩」背後的三根柱子。

對客戶決策的具體影響

  • 錢:導入這三個地基通常需要 Redis 等基礎設施(雲端月費約 NT$300–1,500 起,視規模),但省下的是尖峰當機的客訴與流失的訂單。
  • 時程:初期就規劃 Session/Cache/Queue,比上線後「網站一慢再回頭重構」便宜得多。
  • 風險:沒有這三個地基,網站平常看起來正常,一遇到促銷、報名尖峰就慢、就當、就重複寄信——問題只在「人多的那一天」才爆。

你該問廠商的 5 個問題

  • 我的 Session 存在哪裡?未來如果要擴充到多台伺服器,會不會需要重做?
  • 哪些頁面或查詢會做快取?資料更新後,快取多久會反映最新內容?
  • 哪些工作會丟到 Queue 背景處理?如果背景失敗(例如信沒寄出)會怎麼重試與告警?
  • 尖峰(例如報名開放、促銷)時,這套設計預估能同時扛多少人?
  • 這些基礎設施(Redis、Queue worker)的月費大概多少,算在誰的帳上?

常見問題 FAQ

我的網站很小,也需要這三個嗎?

不一定全都要。流量小、功能單純的形象網站,快取可能就夠;但只要有登入、會員、下單、寄信或尖峰報名,Session 與 Queue 就會明顯派上用場。重點是「按需求導入」,不是全套硬上。

Cache 會讓客人看到舊資料嗎?

設計不當會。好的做法是為不同內容設定合理的「有效期限」與「資料更新時清快取」規則,讓熱門內容快、但重要資料即時。

Queue 失敗了,信沒寄出怎麼辦?

成熟的 Queue 設計會自動重試、失敗會進「死信」清單並告警,讓工程師補救,而不是默默消失。簽約時可以問清楚重試與告警機制。

這些是不是只有大網站才需要?

不是。真正決定要不要導入的,是「你會不會有尖峰、有沒有登入與背景工作」,而不是網站大小。很多中小網站正是在促銷或報名日當機,才發現少了這三根柱子。

行動呼籲

看不懂報價單上的 Session、Cache、Queue,或擔心網站在報名/促銷尖峰會當機?預約 ScriptWalker 免費 30 分鐘技術諮詢,我們用你聽得懂的話,幫你判斷你的網站需要哪幾根柱子、月費大概多少:

分享: