短鏈服務衝十萬 QPS：先別急著加 Redis，這題首先是定義題

2026 年 10 月 16 日，掘金作者「bug 菌」發布了一篇約五十分鐘閱讀量的長文，討論一個聽起來很誘人的週末挑戰：把短鏈跳轉服務推到每秒十萬次請求（QPS），能不能靠加 Redis 做到？作者的答案相當節制。文章明確聲明，這不是一篇虛構「週末實測達標」的戰報，十萬 QPS 是要驗證的目標，而非已經達成的成績。

這個起手式本身就值得注意。多數高並發教學文的套路是「我加了快取，數字翻倍，結案」，這篇卻把整個問題倒過來問：在談優化之前，你確定自己優化的那個數字，量的是你想量的東西嗎？

十萬 QPS 到底量的是什麼

短鏈服務的業務邏輯三行就寫得完：營運生成一條短網址放進簡訊或海報，使用者點擊，服務查出原始地址，回一個 302 重定向。一個下午就能做出可演示的版本。麻煩從傳播開始之後才出現：同一條連結被大量使用者同時點擊，生成請求很少，跳轉請求卻短時間內集中湧入。

作者給了一個可操作的定義：在指定測量窗口內，短鏈入口成功處理的 GET 請求數除以窗口秒數，而「成功」必須同時滿足返回 302、且 Location 與預期地址一致。建立短鏈的請求單獨統計，缺失與過期連結的 404 也單獨列出。換句話說，伺服器能飛快地回「查無此碼」，並不能證明跳轉能力強。

這個定義動作的重要性，做過壓測的人一看就懂。文章點出一個常見陷阱：跳轉介面回了 302 之後，壓測工具可能繼續去訪問目標網站，最後報表上的耗時，究竟是在測你的短鏈服務，還是在替別人的網站做體檢？測量方式錯了，後面所有優化都是在給錯的數字擦脂抹粉。

十萬這個數字本身有多重

文章做了一筆帳。十萬 QPS 持續一分鐘是六百萬次請求，十分鐘是六千萬次。即使每個回應只按 512 位元組估算，僅回應資料就約每秒 51.2MB，這還沒算請求封包、TLS、TCP/IP、乙太網路開銷與重傳。回應本文幾乎是空的，不代表網路會自動忽略它：狀態行、回應頭、連線管理、負載均衡器，全都不是免費的。

另一個常被混淆的概念是並發數。作者用利特爾定律算了一筆帳：假設系統每秒完成十萬個請求，平均每個請求停留二十毫秒，那麼在穩定條件下，系統平均在途請求數約為兩千。這兩個數字經常被混著講，但「系統裡同時有兩千個請求」和「系統每秒吐出十萬個回應」，是兩件需要分開驗證的事。

這與我們先前分析的餘額扣減在高並發下為什麼會扣錯是同一類問題：程式邏輯看起來沒毛病，真正的考驗發生在流量集中湧入、共用資源開始排隊之後。短鏈服務的資料庫一開始查得飛快，等到連線池排隊、快取失效、例項擴容、流量穿過負載均衡器與公網鏈路，原本不起眼的那次查詢就突然有了很多同伴。

加 Redis 之前，先看那些不顯眼的限制條件

對已經維護過線上系統的讀者，作者認為更值得看的是限制條件。他點出了幾個容易踩的坑：一次 fsync 為什麼不該拖慢所有跳轉；熱點命中率怎樣誤導測試結果，如果壓測反覆打同一批短碼，快取命中率會漂亮得不像真實流量；快取失效的瞬間，為什麼會突然出現資料庫請求洪峯；以及怎麼證明吞吐量的提升沒有拿正確性去換。

這些問題指向同一個結論：Redis 是方案的一部分，但把十萬 QPS 當成「加個快取就能達標」的裝修工程，會在測量階段就翻車。文章的實驗路徑是先用 Go 標準庫搭一個可運行、可持久化、可驗證並發行為的單機版本，再討論壓測設計與瓶頸識別，最後才談到為什麼生產級擴容通常會走向 PostgreSQL、Redis 與多例項部署。

所以呢

這篇文章對不同讀者有不同用處。剛接觸高並發服務的人，可以跟著實作理解請求路徑、隨機短碼、冪等、故障恢復與壓測模型；維護過線上系統的人，看的是那些限制條件。

放在更大的脈絡裡，它示範了一種對待效能數字的態度：先問十萬是客戶端計畫發出的請求、網關收到的請求，還是成功返回正確地址的回應；是在本機回環網卡跑一分鐘，還是跨機器帶著 TLS、日誌與故障注入穩定跑十分鐘。這幾個版本的難度完全不是一回事。對照我們曾討論過的Redis 竟然能當搜尋引擎用，同樣的邏輯也成立：選型與優化之前，先把量測條件與場景邊界講清楚，結論才有意義。

一個週末能不能把短鏈服務推到十萬 QPS？在這篇文章的框架裡，這個問題的答案取決於你怎麼定義「推到」與「十萬」。而把定義講清楚這件事，往往比加 Redis 難得多，也重要得多。