無狀態的定義很精確：處理一個請求時，不依賴前一個請求留在本機記憶體或本機磁碟的資料。每個請求要嘛自帶所需的一切、要嘛從共享的外部儲存讀。判斷一個服務是不是無狀態，有一個乾淨的測試：隨機停掉一台實例、把它的流量重新分配到其他台，如果用戶完全無感，就是無狀態；如果有些用戶的資料不見了（購物車空了、上傳中斷、連線斷掉），那台實例上有本機獨佔的狀態。

破壞無狀態的常見寫法

本機狀態很少是故意留的，多半是幾種常見寫法不知不覺帶進來的。把這些列出來，才知道要外置什麼：

• 本機 session：把登入後的 session 存在實例的記憶體裡。這是最典型的——那個用戶的後續請求只能回到這台，換一台就等於沒登入。
• 上傳暫存：分段上傳的檔案先存本機磁碟再組合。上傳到一半換實例，前面的分段在別台、找不到。
• 本機快取：把計算結果快取在進程記憶體。功能上不算錯（快取失效重算就好），但會讓不同實例的快取不一致、命中率隨實例數稀釋。
• WebSocket 或長連線：連線本身綁在某台實例上。連線的狀態（訂閱了什麼、在哪個房間）留在那台，實例掛了連線得重建。
• 本機定時任務：在每個實例上都跑同一個 cron。多實例時這個 job 會被執行多次——這是無狀態的一個真例外，下面單獨談。
• 跨請求的記憶體狀態：任何「這次請求改了一個全域變數、下次請求會讀到」的設計，都把狀態綁死在單一實例上。

隱式狀態比顯式的更難抓

上面那些是顯式的狀態，比較容易發現。更難抓的是隱式狀態——那些不長得像「狀態」、但實際上綁在某台實例上的資料。在途的資料流（一個還沒處理完的 streaming 請求）、TLS 的 session resumption（重用前一次握手的參數）、限流器的計數狀態（這台記得某個 IP 打了幾次）、以及連線的預熱狀態（這台跟資料庫的連線池已經熱好了）。這些在單實例時完全無感，一旦水平擴展，「這台記得、那台不記得」的落差就會冒出來——限流在每台各算各的、預熱在新實例上還沒完成。抓隱式狀態要用前面那個測試：真的停一台、看有沒有狀態只有它記得。

外置狀態，讓實例對等

做到無狀態的辦法是把狀態從實例本地移到共享的外部儲存。本站 collector 是個乾淨的例子：collector 實例不在記憶體保存任何查詢狀態，所有持久化的資料都在 PostgreSQL，所以任何一個 collector 接收的事件，都能被任何一個 dashboard 查到。實例之間沒有需要協調的狀態，負載平衡用 round-robin 或 least-connections 隨意分配、不需要 sticky session——因為 collector 不保存 session 狀態，哪台接都一樣。

實例並非真的一點記憶體狀態都沒有。collector 有一個固定容量的背壓 buffer（一個 channel），這是一種留在本機的 in-memory 狀態。但這種狀態是易失的緩衝、不是需要持久的業務狀態——事件要回了 202 才算收下，buffer 滿了就回 429，所以實例 crash 掉這段 buffer 不影響資料正確性。無狀態不是「零記憶體狀態」，是「沒有 crash 掉會遺失業務正確性的本機狀態」。這個區分很重要：易失的緩衝可以留在本機，需要對帳、需要持久的狀態才必須外置。

定時任務是無狀態的例外

有一種工作不能讓每個實例各跑一份：定時任務。降採樣、清理、對帳這類 job，如果每台實例都跑，就會被執行 N 次——重複扣款、重複清理、對帳算錯。這是無狀態設計裡一個真正的例外：實例本身無狀態、可以任意增減，但這個 job 必須跨實例互斥、只由一台執行。

處理的辦法是把「誰來跑」這個決定也外置。用 PostgreSQL 的 advisory lock 或外部的分散式鎖，讓要跑 job 的實例先搶鎖、搶到的才跑、其他的跳過。這樣實例仍然對等（誰搶到誰跑，不指定特定一台），但 job 保證只執行一次。水平擴展一個有定時任務的服務時，這是最容易漏掉的一步——擴展前 job 每天跑一次，擴到三台後突然每天跑三次。

下一步路由

• Session 該怎麼處理（sticky、外部 store、還是無狀態 token）→ Session 處理
• 外置的狀態放哪種共享儲存 → Shared storage 選型
• 無狀態是水平擴展的前提，前提本身 → LB 是水平擴展的前提
• Collector 多實例的完整 stateless 設計 → Monitoring Collector

Sticky session：綁實例，最省事也最受限

Sticky session 把同一個用戶的 session 綁定到某台實例，session 資料就存在那台的記憶體裡。它最省事——不用改應用、不用外部依賴，登入狀態放本機就好。代價是它直接破壞無狀態：那台實例掛了、被縮容、或被重啟，綁在上面的 session 全部消失，那些用戶要重新登入。負載也會不均，因為熱門 session 集中在某幾台。sticky 的完整取捨在 負載分散演算法 的黏著段講過，這裡的重點是：它是三種途徑裡對水平擴展最不友善的，通常是暫時的過渡、不是目標狀態。

外部 session store：實例對等，但 session 是 hot row

外部 session store 把 session 從實例本地移到一個共享的儲存，每個實例都無狀態、任何實例都能讀到任何用戶的 session。這讓實例真正對等，是水平擴展下 session 的主流做法。（歷史上還有第四種做法：把 session 在所有實例之間互相複製，讓每台都持有全部 session。它早被外部 store 取代，因為複製流量隨實例數平方成長、擴到一定規模就撐不住——外部 store 用「一份共享」取代「每台一份」，正是為了避開這個。）但這裡有一個選型陷阱：session 是典型的高頻更新資料（每個請求可能都在刷新它的過期時間），放進 SQL 資料庫當一般資料表，會在那幾行 session 上撞出嚴重的鎖競爭——它是典型的 hot row 場景。

所以 session store 通常選鍵值儲存或快取（如 Redis、DynamoDB 這類支援原子操作的）、而不是 SQL。它們的資料模型正好適合「用一個 key 快速讀寫一個 session、高頻更新、不需要跨行交易」，避開了 SQL 在 hot row 上的鎖競爭。這條選型判斷延伸到 Shared storage 選型——高頻的鍵值狀態跟結構化的查詢狀態，適合的儲存不一樣。

無狀態 token：不存伺服器端，但撤銷困難

無狀態 token（如 JWT）把 session 資料簽進 token 本身，發給客戶端隨每個請求帶回來，伺服器端完全不存 session。這是最徹底的無狀態——任何實例收到請求，驗證 token 簽章就知道用戶是誰，不必查任何共享儲存，連 session store 這個依賴都省了。

徹底無狀態的代價在撤銷跟大小。撤銷困難是最關鍵的：token 一旦簽發，在它過期之前都有效，伺服器端沒有一個「登出」按鈕能立刻讓它失效——因為伺服器根本不存它的狀態。要提前撤銷（用戶登出、帳號被停用）就得額外維護一個撤銷清單，那又把無狀態的好處吃掉一部分。大小是另一個代價：token 隨每個請求傳輸，塞太多資料會讓每個請求都變重，所以 token 只適合放少量、非敏感的識別資訊，不能當通用的 session 資料容器。無狀態 token 適合「短期有效、不需要即時撤銷」的場景，需要即時登出、需要存較多 session 資料的，還是走 session store。

Session 一致性：剛寫完要讀得到

三種途徑之外，session 還有一個一致性問題會在水平擴展、讀寫分離後浮現：剛寫完的資料，馬上讀要讀得到（read-after-write）。當讀路徑走了資料庫的唯讀副本、而副本有複製延遲時，一個用戶剛更新完 session（或剛下單、剛改了餘額），下一個請求若打到副本，可能讀到還沒同步過來的舊資料。

解法是選擇性地路由，而不是把所有讀都無差別送回主庫：用一個 session token 標記「這個 session 剛寫過」，在複製延遲的那個時間窗內（幾秒），把它的讀強制走主庫；過了窗、或本來就容忍稍舊資料的讀（看別人的公開資料、看報表），走副本就好。session 一致性因此是按查詢分類的——不可容忍舊資料的（剛寫完查自己、餘額確認）走主庫，容忍的走副本。這個補丁要花多少工，其實取決於底層的複製延遲有多大，而那是 Shared storage 選型 的 replication 架構決定的。

下一步路由

• 高頻鍵值 vs 結構化查詢 vs 大檔，各放哪種共享儲存 → Shared storage 選型
• 把 session 從實例本地移出去，是無狀態設計的一部分 → Stateless 設計原則
• sticky session 的黏著代價與演算法 → 負載分散演算法
• 狀態放哪決定了之後，憑證靠什麼帶進每個請求（cookie 自動附上 vs 請求標頭明確附上）→ 7.36 憑證在請求中怎麼帶
• 外洩當下撤不撤得掉，由這個決定決定，而它在事件發生時補建不起來 → 7.37 密碼外洩之後

先分清權威狀態與衍生狀態

放進共享儲存的狀態，先判斷它是權威的（canonical）還是衍生的（derived）。權威狀態是唯一真相來源——影響交易、權限、對帳的資料，錯了不能重建，只能從它自己回復，所以要備份、要 audit。衍生狀態是從權威狀態算出來的——快取、搜尋索引、報表，錯了或丟了可以砍掉重建，不需要昂貴的持久保證。

這個區分直接改變選型。一個購物車若是正式的交易狀態（下單的依據），它是權威的，要放能持久、能備份的儲存；若只是「暫時記住用戶點過什麼」的方便快取，它是衍生的，放一個失效可接受的快取就好。判反方向的代價是兩種：把權威狀態放進會被清掉的快取（丟資料）、或把衍生狀態塞進要嚴格備份的儲存（付不必要的成本）。

按存取型態選儲存類型

存取型態決定放哪一類儲存，三類常見的共享狀態各有適合的落點：

• 結構化、要查詢的狀態 → 共享的關聯式資料庫。本站 collector 的水平擴展就靠這個——多個 collector 實例寫入同一個 PostgreSQL，任何實例接收的事件都能被任何 dashboard 查到。這裡有一個關鍵限制：不是所有資料庫都能當共享儲存。collector 的 SQLite 後端不支援水平擴展，因為每個實例有各自的 SQLite 檔案、無法合併查詢，且單檔案模型無法跨主機存取——這也排除了「把 SQLite 檔放 NFS 給多台共享」這種看似省事的做法。要共享，就要用本身支援多連線並行、能跨主機的資料庫。
• 高頻的鍵值狀態 → 鍵值儲存或快取。session、計數器、限流狀態這類高頻讀寫、不需要跨行交易的狀態，放 SQL 會撞 hot row 的鎖競爭，放 Redis、DynamoDB 這類鍵值儲存才對——這條在 Session 處理 展開過。
• 大檔案、不可變的內容 → 物件儲存。上傳的檔案、靜態資源這類大而不常改的內容，放物件儲存（如 S3）比塞進資料庫合適——資料庫不擅長存大二進位、物件儲存正是為此設計，且本身就跨主機共享，解掉了「上傳暫存放本機、換實例就找不到」的無狀態破口。

共享一個資料庫的讀路徑

多實例共享同一個資料庫時，寫入集中在主庫、但讀取可以擴展——這是讀寫分離。寫走主庫（primary），讀走唯讀副本（replica），讀流量超過主庫吞吐時，加副本就能擴讀路徑。副本有複製延遲要納入考量：同一可用區內的串流複製通常低於 100 毫秒，跨可用區到秒級，跨區域可能到秒至分鐘級且不保證 read-after-write——需要剛寫就讀到的查詢要強制走主庫，這正是 Session 處理 那條一致性補丁。

副本不是無限加的。傳統資料庫的副本要自己重放主庫的日誌、吃 CPU 與磁碟，每加一個副本都增加主庫的複製負擔，所以有數量上限（PostgreSQL 通常 3 到 5 個）。運算與儲存分離的架構（如 Aurora）讓副本讀同一份分散式儲存、加副本不增加主庫的寫入負擔、延遲降到毫秒級、上限也高（Aurora 最多 15 個），代價是綁定特定供應商。讀路徑能擴到多寬，是這個架構決定的，選型時要先算清楚。

共享一個資料庫的連線瓶頸

水平擴展一個共享資料庫的服務，最先撞到的瓶頸常常是連線，不是 CPU 或磁碟。關聯式資料庫每條連線都吃記憶體、吃一個 process 或 thread，上限通常在幾千條；而水平擴展會讓連線數線性放大——每台實例開一個連線池（例如 30 到 50 條），擴到很多台，總連線數就爆了。50 台每台 30 條就是 1500 條，直接被資料庫以「連線太多」拒絕。

解法是加一層連線池中介（如 pgBouncer）做多工：讓大量的應用端連線共用少量的資料庫端連線。1500 條應用連線經過中介，可以多工到 200 條資料庫連線。多實例共享同一個資料庫時，這層中介幾乎是必要的——跳過它直連，連線會在擴展的某個規模突然爆掉。連線池、交易邊界、讀寫分離的完整資料庫側設計，在 backend 高併發存取 展開，這裡要確立的是：共享資料庫是水平擴展的落點，但它的連線與讀路徑有各自的天花板，選型時要一起算。

下一步路由

• 高頻的 session 狀態為什麼要放 KV 而非 SQL → Session 處理
• 什麼狀態該外置、什麼可以留本機 → Stateless 設計原則
• 連線池、讀寫分離、交易邊界的資料庫側深入 → backend 高併發存取

擴展前先窮盡低成本手段

加實例是有成本的手段，不該是遇到壓力的第一反應。一個健康的擴展決策，會先窮盡零成本或低成本的手段，確認真的不夠了才擴機。以讀取變慢為例，加副本或加機器之前，先做過補索引、讓儀表板改讀預聚合的摘要表、把降採樣 job 調到避開高峰時段——這些預聚合類的手段常常是「加機器前」最有效的降載，做完可能就不需要擴了。擴展的觸發原則是按觀察到的真實瓶頸行動、不按預測搶跑，且在擴機之前先把便宜的優化用盡。

觸發訊號分層，各層對應不同動作

擴展的觸發不是單一訊號、單一動作，成熟的系統分層應對。本站 collector 的 ingestion 就分四層防線，每層有各自的觸發條件與動作：源頭的 SDK 在超過粒度時自動降取樣、單機的背壓與限流在寫入接近滿載時擋、水平擴展在單機 CPU 或連線飽和時加實例、佇列解耦在突發流量超過整個 collector 群的即時處理能力時插入緩衝。訊號從源頭到基礎設施逐層升級，先用便宜的層擋，擋不住才動到貴的層。

共享儲存的擴展也有量化的觸發訊號。collector 的 SQLite 後端撞到「database is locked 每分鐘出現一次以上」或「聚合查詢超過 3 秒」，就是該換 PostgreSQL 的訊號；PostgreSQL 撐到每秒數萬筆持續寫入或需要自動降採樣，就是該換時間序列資料庫的訊號。這些訊號的共通原則還是那條：按觀察到的瓶頸切換，不按預測提前重構。

縮回要先 drain，不能硬砍

縮回的核心難點是實例身上還有活。減一台實例前，要走跟關閉服務同一套收束流程：先把它從負載平衡的目標裡摘掉（停止送新流量）、等它手上的在途請求處理完、再真正終止。這跟 模組四 graceful shutdown 是同一套機制——縮容其實就是一次有計畫的實例退場，退場的固定順序（摘流量、drain、終止）在那裡展開。硬砍一台正在處理請求的實例，那些請求全部中斷，用戶端看到的就是一批莫名其妙的失敗。

縮回還有兩個容易出事的地方。一是縮太快造成容量不足——流量剛回落就急著縮，結果下一波又上來、新實例還沒起好。二是縮縮擴擴的抖動，訊號在門檻上下跳、實例反覆增減，這靠冷卻時間（cool-down）壓住：擴或縮之後強制等一段時間再判斷，不讓它對每個瞬間波動都反應。擴縮該選哪個訊號、冷卻時間怎麼配，在 規模拐點判斷 的擴縮訊號段有完整對照。

有一種源頭的縮回不靠減實例，而靠降載。collector 的背壓 buffer 滿了就回 429 加一個 Retry-After，SDK 收到 429 自動把取樣率從 1.0 降到 0.5、再降到 0.1；等連續成功幾十次，再逐步回升到 1.0。這是一個閉環的自動降載與恢復——不加機器、直接在源頭把進來的量壓下去，撐過尖峰再放回來。對短暫的高峰，這種源頭降載比擴實例划算得多。

該擴、還是該解耦

擴展到某個點會遇到一個判斷：繼續加實例、還是改變架構。當 collector 群已經水平擴展、仍無法即時消化突發流量時，繼續加實例的邊際效益在下降，這時該考慮插入一個佇列解耦——collector 簡化成「接收、驗證、寫進佇列、回 202」，後面的 worker 按自己的速度消化積壓，把「即時處理」換成「保證不丟、慢慢處理」。但這個決策有反向的一面：如果只是短暫的高峰，佇列的維護成本可能高於它的收益，這時回到源頭用動態取樣降量更划算。佇列解耦的完整設計在 模組七 突發流量 展開，這裡的判斷點是：加實例、源頭降載、佇列解耦是三個不同成本的選項，按尖峰是短暫還是持續來選。

下一步路由

• 什麼訊號代表系統進入飽和、該擴容 → 規模拐點判斷
• 縮回的實例退場順序、drain 怎麼做 → 模組四 Graceful shutdown
• 佇列解耦怎麼接、突發流量的完整應對 → 模組七 突發流量
• 垂直還是水平——擴的方向怎麼選 → 垂直與水平擴展的判斷

兩種擴展的機制、各自的物理與成本天花板，在 規模拐點判斷 的垂直對水平段展開過（垂直有兩道牆——換更大的機器會撞到物理規格上限、以及成本在高階機型非線性飆升；水平則有協調與連線放大成本）。這一章不重述那些機制，聚焦在「怎麼用無狀態與否做這個判斷」。

先問能不能無狀態

判斷從一個問題開始：這個要擴的元件是無狀態的、還是有狀態的。無狀態的部分（API server、worker）水平擴展幾乎無腦——每個實例對等、加一台就多一台的容量，這個模組前面幾章的設計就是為了讓服務落在這一邊。有狀態的部分（資料庫、快取、session store）不能靠複製水平擴展，因為狀態不對等——不能開兩台資料庫主庫同時寫、期待它們自己一致。

把這個前提判反，是水平擴展最常見的撞牆方式：用水平擴展的策略去動一個有狀態的服務，加了實例卻發現狀態沒有跟著分攤，QPS 沒漲、甚至因為協調成本更慢。判斷的第一步永遠是先分清楚：這個元件是無狀態的（水平的候選）、還是有狀態的（要另一套策略）。

有狀態的節點：垂直撐，讀路徑用副本擴

有狀態的節點（典型是資料庫主庫）擴展走另一條路。寫入的部分靠垂直撐——換更大的機器,不改程式、立即見效，適合這種不能水平複製的關鍵節點。但垂直有天花板，且有狀態的關鍵節點常常比機器規格更早撞牆（交易型資料庫主庫的真實上限往往卡在架構因素、不是規格不夠），這條在拐點判斷那章講過。

垂直撐主庫的同時，讀路徑可以水平擴——加唯讀副本分攤讀流量，這是 Shared storage 選型 的讀寫分離。所以一個有狀態的資料庫，實際的擴展是混合的：寫路徑垂直撐、讀路徑用副本水平擴。垂直撐到頂、讀副本也不夠時，最後一步是分片（sharding）——把資料按某個鍵拆到多台，每台只管一部分，這才是有狀態服務真正的水平擴展，但它要重新設計資料的切分方式，成本最高、留到前面手段都用盡才動。

混合是常態，不是二選一

真實系統極少是純垂直或純水平，而是按層混合：無狀態的應用層水平擴（加實例）、有狀態的資料層垂直撐加讀副本（撐不住再分片）。這對應一個擴展框架的三個方向——複製（把無狀態的元件多開幾份）、功能拆分（把不同功能拆成獨立服務、各自按自己的需求擴）、資料分片（把有狀態的資料按鍵拆開），常常同時在動、不是選一個。這個框架（AKF Scale Cube）的完整拆解在 backend 擴展軸。

判斷的收斂是這樣：先問這一層能不能無狀態。能，就水平複製，這是最便宜的擴展。不能，先看改造成無狀態的成本值不值得；不值得或改不動，就垂直撐這個節點、讀路徑用副本水平擴、撐到極限再分片。每一步都是在「這個元件的狀態能不能被分攤」這條線上做選擇——這也是為什麼水平擴展這個模組，從頭到尾都在講無狀態。

下一步路由

• 垂直的兩道牆、水平的隱性成本、擴展框架的完整機制 → 規模拐點判斷
• 怎麼把一個服務改造成無狀態 → Stateless 設計原則
• 讀寫分離、讀副本、分片的儲存側設計 → Shared storage 選型
• 擴與縮的觸發訊號、縮回怎麼做 → 擴展的觸發與縮回