一次一筆的處理與它的互斥範圍

一個服務的需求裡，通常有一件事必須一次只處理一筆（業界常稱為 serialization point）：同一張票不能同時賣給兩個人，同一筆訂單不能同時被付款與取消，同一個交易對的委託要依單一順序撮合，同一個短代碼不能同時分配給兩個長網址。這件事要靠鎖、單一執行緒或條件更新依序處理，所以不論前面有多少台伺服器，抵達這件處理的請求都要逐一通過，負載最後集中在這件處理上。

決定有多少請求要依序等候的，是互斥範圍：哪些請求彼此必須輪流處理。互斥範圍有三個來源：需求、資料的表示方式，以及把多個範圍放進同一個依序處理的執行者。

售票的需求要互斥的只是同一張票；全場庫存若寫成一個計數欄，所有購票請求都更新資料表的同一列，整場的請求依序等候同一把鎖，這種情形叫熱點列（hot row）。改成每張票一列，而且認領的寫法讓每個請求各自挑到不同的列（例如跳過別的交易已經鎖住的列，寫法在 9.0.1 售票搶購的負載路徑 的〈扣庫存：資料庫逐張認領與加入 Redis 閘門的條件〉），只有搶同一張票（同一個座位）的請求才需要輪流；認領時若每個請求都挑「第一張還沒賣出的票」，所有請求仍會撞在同一列上。表示方式造成的互斥範圍，在實作上表現為鎖的粒度（lock granularity），可以靠改寫法縮小。熱點列的排隊機制與分散寫入的做法在 1.18 高頻計數的寫入與彙總。

撮合的需求要互斥的是整本委託簿（同一個交易對上還沒成交的買賣委託），因為一筆委託是否成交取決於簿上所有其他委託的價格與時間；這是需求要求的下限，換表示方式也縮不小。撮合引擎以單一執行緒依序處理、沒有用鎖，而同一條執行緒或同一份依序日誌裡放的交易對越多，互斥範圍就越大：LMAX 把所有市場放在一條執行緒上，這時範圍是整個交易平台；依交易對分開撮合引擎，是把範圍縮回一本簿（Single Writer Model；兩種做法在 9.0.2 交易撮合的負載路徑 的〈撮合引擎：單一寫入者與記憶體內的委託簿〉）。

需求本身可以協商時，互斥範圍也能縮小。廣告平台允許預算小幅超支，就可以把一個廣告活動的預算預先切成多份額度、分給各台伺服器各自扣，定期同步，互斥範圍從整個活動縮到一台伺服器上的那一份，代價是超支有上限而不是零。撮合沒有這種空間：不論撮合規則是價格與時間優先，還是依比例分配，一筆委託的成交都取決於整本簿，所以在一本簿之內，撮合能做的只有讓依序處理的那一條路徑變快。

能在一次一筆的處理之前回應的請求

需要經過一次一筆處理（必須依序、不能並行處理的那件事）的請求（購票、下單、委託、建立短網址）裡，有三類在進入那件處理之前就能回應：格式、權限或帳戶狀態不符的請求（例如餘額不足）在入口就能拒絕，結果已經確定的請求可以直接告訴它結果（票賣完之後的購票請求），以及重送的請求可以回傳上一次的結果。同一段時間內，這三類請求的筆數在所有需要經過一次一筆處理的請求筆數裡所佔的比例（分母包含這三類本身），下文稱可提早回應的比例；這個比例越高，前面的元件擋下的越多，一次一筆的處理承受的越少。

提早回應的元件讀的是一次一筆的處理所持有狀態的副本（售票的剩餘數量、帳戶餘額），副本會落後。一旦確定就不再改變的結果可以安全地提早回應；會回頭的狀態（帳戶餘額、付款期限到期時被放回的票），提早回應的只是暫時的結果，而副本落後造成的錯有兩個方向，補救各不相同。副本把請求判成不行（已售完、餘額不足），可能是錯拒，所以要讓使用者能再試；副本把請求判成可以而放行，副本可能已經過時，所以通過提早檢查的請求一律要在一次一筆的處理裡再檢查一次，否則餘額會透支、票會超賣。

可提早回應的比例由需求的性質決定。售票的成功請求總數有上限（票數），票數之外的購票請求結果在售完那一刻就確定（直到付款期限到期、有票被放回為止），所以比例高；交易撮合沒有這種上限，一筆委託的結果要撮合當下才知道，只有無效的委託能提早回應，比例低。成功請求的總數有上限，不保證比例高：拍賣的成功請求總數是一（只有一個得標者），而結標之前每一次出價都要處理、誰得標事先不知道。

比例高的系統，負載保護的重心在一次一筆的處理之前：排隊、提早回應，把請求擋在資料庫前面。比例低時，比對同一個互斥範圍每秒到達的請求數與依序處理一個範圍的處理量。到達的請求數低於處理量時（checkout 的每一筆訂單、一般帳戶的轉帳），一次一筆的處理不是瓶頸，負載先耗盡的是別的資源（連線數、資料庫的總寫入量），見〈每一段保護把負載轉到哪裡〉。到達的請求數高於處理量、而範圍能靠改表示方式縮小時（熱門商家的收款帳戶改成只新增入帳紀錄），回到〈一次一筆的處理與它的互斥範圍〉的熱點列。範圍縮不小時（一本委託簿、結標前的一件拍品），同一個範圍的全部請求都要通過同一個依序處理的執行者，重心才落在那件處理本身：記憶體內的狀態、單一寫入者、處理路徑上沒有資料庫，以及事先配置的容量。

多出來的請求：排隊、拒絕或請使用者重新確認

扣掉能提早回應的請求，抵達一次一筆的處理（例如扣庫存或撮合）的請求仍可能超過它的處理量，多出來的那些要決定怎麼處置，而決定的依據是延遲是否改變請求的價值。售票在不劃位、固定票價時，排隊幾分鐘之後買到的仍是同一種票、同一個價格，多出來的請求可以排隊（Admission Control），放行的速率設在後端實測的處理量。連續撮合的交易所，一筆委託晚一秒送進委託簿，市場已經變了，市價單以偏離預期的價格成交，排隊讓請求失去下單時的意義。所以委託到達時以佇列長度除以處理速率預估要等多久，預估超過委託延遲目標就在接受之前明確拒絕（Load Shedding；9.0.2 的閘道以佇列長度的上限做這件事）。

延遲改變價值、所以要拒絕，還有一個前提：請求在處理時照送出當下的條件直接執行，不再經使用者確認。處理之前會讓使用者重新確認的請求，延遲的代價只是多一次確認：checkout 的價格在使用者排隊期間變了，下單時以新價格重算並請使用者確認，訂單照樣成立。市場的規則也會改變這個判斷：集合競價是把一段時間內的委託集中起來、以單一價格一次撮合的規則，以固定間隔做集合競價的市場，等到下一次撮合本來就是規則的一部分。

被拒絕的用戶端會重送時，負載以重送的形式回來：用戶端是程式時往往立刻重送，重送的請求疊在原本的需求上，讓進來的請求率高於真實的需求，這是 Retry Storm。所以拒絕的回應要帶重試的時機（Retry-After 這類欄位，或約定加上隨機延遲的退避間隔，見 Jitter），排隊的回應要讓使用者看得到自己的位置，拒絕與排隊的回應都在讓用戶端不要用重送去確認結果。逾時就作廢的用戶端（廣告的即時競價）不會重送，拒絕本身就是結果。

每一段保護把負載轉到哪裡

把請求擋下或延後的機制（邊緣快取合併回源、速率限制、排隊放行、Redis 閘門、機器人偵測），本篇統稱保護，實作它的程式或服務是保護元件。每一段保護擋下或延後某一類請求（可以提早回應的、還沒輪到的），被擋下的請求並沒有消失，改由保護元件承受，或轉給保護後面的下一個元件，承受的那一方會先耗盡某種資源；保護也會讓下游出現新的上限，或讓同一個請求被處理不只一次（去重的做法在〈佇列、使用者重按與回呼帶來的重送與去重〉）。邊緣快取合併回源與機器人偵測把負載留在邊緣，速率限制、排隊放行與 Redis 閘門把它轉到保護元件自己的狀態與連到它的連線上，排隊放行另外帶來位置查詢；保護把請求順利送到下游之後，負載轉到最慢的接收端與第三方業者的配額。

保護元件自己的狀態。排隊的順序、已發出的進入資格與速率限制的計數，要存在保護元件的程序以外，重啟之後才接得下去（〈保護元件故障時的輸出：停止放行、全部放行、保守的固定上限與預設值〉）。每一次入列、位置查詢與計數都是對那個儲存的一次寫入或讀取，而它承受的是全部到達的請求，不只放行之後的請求，所以它的容量要以到達的請求率規劃（Rate Limit 的計數儲存是同一件事）。

連線數。連到一個元件的連線數，等於應用程式這一側同時在執行的單位數（程序、執行緒或協程）乘以每個單位各開的連線數，或在用連線池的執行環境裡，等於每個程序的連線池大小乘以程序數。把扣庫存或計數從資料庫移到 Redis 這類記憶體儲存，資料庫的鎖等待少了，連到新儲存的連線數卻成為新的上限。PHP-FPM 這類每個請求佔一個 worker 的執行環境，連線數的上限是全部主機的 worker 總數（每台的 pm.max_children 乘以主機數），為了尖峰把主機擴到幾十台時，總數可能超過 Redis 預設的 maxclients（一萬；Redis 行程的檔案描述元上限不夠時，實際的上限是那個上限減 32，可能低很多）。持久連線（phpredis 的 pconnect）讓每個 worker 長期保留一條連線，閒置的 worker 也佔著一條，省下的是每次請求的握手，連線數不會變少；要讓連線數少於執行單位數，要在中間放一層連線代理（例如 twemproxy，它對後端維持少數的持久連線）。沒有持久連線時，每次新開連線要付 TCP 握手的成本，用完的連線在主動關閉的那一端（通常是應用程式這一端）停留在 TIME_WAIT 狀態，佔住應用程式主機的本機連接埠。資料庫連線的同一件事在 9.14 連線池放大解法。

輪詢。排隊把請求從資料庫移開，排隊中的使用者卻會反覆查自己的位置，每秒的查詢數是等候人數除以查詢的間隔（9.0.1 的假設：十萬人每五秒一次，每秒兩萬個），落在排隊服務上。讓每一次查詢便宜（位置資訊放在記憶體或邊緣），讓查詢變少（由伺服器在回應裡指定下一次查詢的間隔），或改成伺服器推送；改成推送時，等候中的每一條連線都是要規劃的容量。

下游的接收端。一個元件若把輸出直接送給每一個接收端、等接收端收下才處理下一筆，最慢的那一個接收端決定了整個元件的處理速度，負載以 Backpressure 的形式傳回來。把輸出先寫進一份日誌，由另外的發布服務送給各個接收端，接收端跟不上時，延遲的只是送到它那裡的資料。

外部的配額。第三方業者（金流、簡訊、雲端 API）對每個商家的速率限制會成為下一個上限。這個上限由業者設定，所以只能事先查到數字、在尖峰之前向業者申請提高；超過時業者回錯誤（例如 HTTP 429）或變慢，所以要在自己這一側排隊，以不超過配額的速率送出；呼叫業者的請求若和其他流量共用同一個連線池，業者變慢時等待中的請求會佔住其他請求也要用的連線，所以呼叫業者用獨立的連線池與逾時（Bulkhead）。

佇列、使用者重按與回呼帶來的重送與去重

把請求放進佇列延後處理，會讓同一個請求被處理不只一次。佇列在消費端以確認（ack）模式使用時保證的是至少送達一次，消費端處理到一半當機、佇列重送，同一個請求會被處理兩次。請求在進入佇列之前要有一個識別碼（Idempotency Key），處理那一段以它辨認重送：辨認重送與狀態改變寫在同一個交易裡（以識別碼當唯一鍵寫入結果），識別碼至少保存到用戶端不會再重送為止；先查一個快取、再寫資料庫的寫法，在兩步之間當機或兩個重送同時到達時仍會重複。識別碼若在使用者那一次操作時就由用戶端產生（表單載入時產生、重按時沿用），使用者重按也辨認得出；識別碼在入列時才由伺服器產生時，使用者重按產生的是新的請求，佇列分不出來，要以業務規則限制（例如一個帳號同時只能有一筆在排隊，在進入佇列時檢查）。排程服務與第三方的回呼同樣可能把同一件事送兩次，條件更新（UPDATE ... WHERE status = 'pending'）讓第二次執行更新零列；對外的動作（寄信、出貨、呼叫退款 API）要在更新了一列之後才做，寫在更新之前、或不看更新了幾列就執行的動作，仍會做兩次。只靠「之後才做」還會漏做：更新提交之後、對外動作完成之前當機，重送時更新零列，動作就被跳過。所以待執行的對外動作和狀態改變寫在同一個交易裡，由另一個程序讀出、至少送一次（Outbox Pattern），呼叫業者時帶業者的冪等鍵（例如 Stripe 的 Idempotency-Key），讓至少一次的送出在業者那一側只生效一次；業者不支援冪等鍵時，以對帳找出重複或漏做的動作。

保護元件故障時的輸出：停止放行、全部放行、保守的固定上限與預設值

保護元件故障時的處置有三種：停止放行（fail closed）、全部放行（fail open），以及介於兩者之間、退回一個保守的固定上限放行。選擇時先分出保護擋的是什麼。權限檢查、餘額檢查、詐欺評分與法規要求的檢查擋的是不該進來的請求，放過去就違反不能讓步的需求，而停止放行的代價是整個服務停擺，所以這一類再依它在檢查順序裡的位置分開處理。之後沒有其他檢查的權限與法規檢查，故障時停止放行，全部放行的結果是越權或跳過法規要求的檢查。後面還有權威檢查的前置檢查（閘道上的餘額檢查，最終檢查在一次一筆的處理裡），故障時可以放行給權威檢查。權限檢查可以先用快取的最近決定繼續放行，代價是權限被撤銷之後，要等快取到期才生效。詐欺評分漏掉的損失有上限、事後可以經由拒付追回部分金額，故障時放行多少是業務決定的損失上限，例如低金額放行、高金額暫停、事後審查。

只用來擋流量的保護（排隊、速率限制、閘門），依下游在故障那一刻要承受的流量選。保護的資源一定處理不了全部請求時（售票的排隊，保護的是扣庫存那一段），全部放行等於拿掉保護，全部請求直接打到必須依序處理的扣庫存，選停止放行，使用者看到的是暫停。保護的資源處理得了全部合法請求、保護只用來擋濫用時（邊緣依來源位址的速率限制），停止放行等於整個服務停擺，選全部放行。保護的資源處理得了全部合法請求、原本會選全部放行的那一類保護，常常正是因為它要擋的那股負載而故障（速率限制的計數儲存在攻擊流量下過載），這時全部放行是在負載最大的時候拿掉保護，所以退回保守的固定上限，它取代的是全部放行，不取代排隊這類該停止放行的保護：共用的限流服務故障時，呼叫它的每一個 API 實例改以本機的計數、每秒放行固定的請求數，這個數字是下游實測的總處理量除以實例數，全部實例加起來不超過下游處理得了的量；實例數會因自動擴充而變時，以最大實例數計算，或在故障期間停止擴充。代價有三個：每個實例只有一個總計數，一個重度呼叫者就能吃光一個實例的額度，所以本機計數也依呼叫者分開；負載平衡不均時有的實例拒絕、有的閒著，實際放行量低於下游處理得了的量；實際實例數遠少於最大實例數時，放行量只剩一小部分，接近停止放行。這個折衷是從機制推出的，只用在擋流量的保護上；擋不該進來的請求的保護照上一段的分法處理。停止放行之後要能在恢復後照原本的順序繼續，保護元件的狀態（排隊的順序、已發出的資格）要存在它的程序以外，只存在記憶體的狀態在重啟時就丟了。

選了全部放行之後，還要確認下游讀到的值代表放行：保護元件故障時，保護元件自己或呼叫它的那一方的備援邏輯會給下游一個值，這個值必須是下游判成放行的那個值。Cloudflare 2025 年 11 月 18 日的事故報告 寫到，機器人偵測讀到一份因為重複的列而變大的設定檔，舊版代理引擎上的所有流量都拿到零分的機器人分數。那套評分的正常範圍是 1 到 99，分數越低越像機器人，零分代表沒有評估（Cloudflare 的 bot score 文件）；客戶的規則寫成低於某個分數就擋，代表沒有評估的零分落在擋的那一側，設了擋機器人規則的客戶因此擋掉了大量的真實流量。保護元件的故障也不只停掉一種，讀到壞掉的規則或設定檔、輸出錯的判斷，是同樣要事先決定處置的情形；那時保護元件還在運作，監控上每一層都顯示正常，這一類異常要靠 4.0.1 監控鏈事前偵測不到的異常 裡的業務結果發現。保護元件是購買的服務（業者提供的等候室、WAF）時，故障時放行還是不放行由業者的行為決定，要事先查清楚業者的預設，以及它能改成什麼。

依賴變慢、部分失效與恢復時的第二波湧入

保護元件與它保護的依賴，失效時也不只停掉或輸出錯的值。依賴變慢時，每一個等待中的請求在逾時之前都佔著呼叫方的 worker 與連線，所以變慢通常比停掉更早耗盡呼叫方，見 9.16 負載超過容量時服務的表現 的〈無回應：程序還在，請求等到逾時也沒有結果〉。部分失效時只有一部分副本連不到依賴（某一個可用區的網路出口壞了），讓那幾個副本下線是對的，而剩下的副本要承接全部流量，容量不夠時接著變慢（Partial Failure；Kubernetes 上的例子在 4.0.3 以監控鏈盤點 Kubernetes 上的電商 checkout 的〈付款服務的 readiness 納入金流業者時的後果〉）。恢復時的第二波湧入：依賴恢復的那一刻，故障期間累積的請求與重試一起到達，讓剛恢復的依賴再過載一次，這是 9.16〈尖峰過去或應對切換之後仍持續的情形：停在失效、擺盪與第二波湧入〉的第二波湧入。第二波湧入本身是一次尖峰，累積的請求送完就結束；重試若把過載維持下去，它就轉成另一種情形：負載退去之後服務仍停在失效（Metastable Failure）。委託簿這種狀態會隨時間失去價值的系統，恢復時還要決定處理的順序，交易所停機後先只收取消、再以集合競價重開的流程在 9.0.2 的〈撮合引擎：單一寫入者與記憶體內的委託簿〉。

延伸閱讀：售票搶購與交易撮合的負載路徑

9.0.1 售票搶購的負載路徑 從全場庫存寫成一個計數欄時熱點列與連線池的耗盡順序起算，走過 CDN 合併回源、排隊放行、資料庫逐張認領與付款期限，示範互斥範圍怎麼靠改表示方式從整場縮到一張票、可提早回應的比例高時排隊服務怎麼提早告訴後面的人買不到，以及什麼條件下才值得在扣庫存前面加一道 Redis 閘門。9.0.2 交易撮合的負載路徑 走過閘道、依序日誌、撮合引擎與行情發布，示範互斥範圍沒辦法縮小、可提早回應的比例低時，負載保護的重心怎麼移到處理路徑本身與事先配置的容量，以及延遲改變請求的價值時，過載與停機後的處置為什麼與售票相反。

例子以服務端監控的分層（4.0）裡的短網址服務為底：一台主機上的入口 Nginx、後端程式、PostgreSQL 與 Valkey，訪客點短網址時由後端查出原本的網址並轉址。這一篇另外假設它把點擊事件寫進佇列做統計，談到負載平衡器時假設後端跑成多個實例；4.0 的版本兩者都沒有。

負載的位置與服務的結果：兩條分開量測的軸

Saturation Point 卡與 9.4 Saturation Discovery 以利用率把負載分成 linear、knee、cliff 三段：利用率低時吞吐量隨負載線性上升，到 knee 之後延遲開始上升而吞吐量的成長變慢，到 cliff 之後吞吐量下降、延遲失控。這三段量的是輸入那一側：負載壓在系統上的位置。服務呈現的結果是輸出那一側：使用者拿到的是一個慢的回應（變慢）、一個錯誤（請求失敗）、一個逾時（無回應，或請求沒有抵達），還是連線被拒（程序終止，連接埠上沒有程式在接受連線）。這是用戶端直接連服務時的樣子；前面有反向代理時，代理把無回應與程序終止轉成 504 與 502，見〈無回應：程序還在，請求等到逾時也沒有結果〉。

兩條軸要分開寫，理由是同一個位置會走到不同的結果。進入 cliff 之後，一個連線池設了等待上限的服務呈現請求失敗，同一個服務把等待上限拿掉就呈現無回應，記憶體先耗盡則呈現程序終止。只寫「進入 cliff」說不出使用者看到什麼，也說不出該用哪一種應對；只寫「回應變慢」說不出離 cliff 還有多遠。描述一次過載時兩條軸都寫：負載在哪一段、呈現哪一種結果。各種結果的應對不同，所以挑應對之前要先判出是哪一種結果；從監控上判的方法見〈各監控層看得到哪一種結果〉，先耗盡的資源怎麼決定結果見〈變慢之後走向哪一種結果：先耗盡的資源與等待是否設有上限〉。

6.2 load test 的〈Saturation 與瓶頸定位〉另把越過 knee（6.2 稱為 inflection point）之後的走法分成逐漸退化型與崩落型：前者延遲緩慢爬升，後者延遲在某一點突然跳升數倍。兩型的差別在走到結果的速度：逐漸退化型會在變慢停留較久，崩落型多半由連線池或執行緒池耗盡造成，很快走到請求失敗或無回應，所以要在比延遲跳升點更低的負載就開始限流。

變慢：延遲超過門檻，請求仍然完成

變慢指請求仍然完成，而完成所需的時間超過服務承諾的門檻。判斷標準寫在 SLO 上：延遲的某個百分位數（p95、p99）在一段時間內超過門檻。看平均值會把尾端延遲蓋掉，看單次請求會被偶發的慢請求誤導；百分位數也要依影響範圍（租戶、分區、端點）分開算，理由與錯誤率相同，見〈請求失敗〉。

非同步的工作沒有回應時間可量，它的變慢是工作被接受、完成時間延後：短網址服務把點擊事件寫進佇列、由背景程式彙總成統計，過載時統計頁上的數字晚了半小時（數字是示意），而每一次點擊都轉址成功。非同步的變慢要量佇列裡最舊的一筆等了多久或消費者落後多少（Queue Depth），量請求延遲看不到它。

變慢的成因是排隊：請求在某個瓶頸前面等，瓶頸可能是 CPU、資料庫的鎖、連線池。CPU 不足時所有請求一起變慢，鎖競爭或單一資源不足時只有用到它的請求變慢。一個請求扇出到多個後端並等全部回來時，任一個後端的尾端延遲都成為這個請求的延遲，所以一個後端過載會讓扇出到它的每一個請求變慢（Fan-out）。應對是先找出瓶頸在哪一層（9.5 瓶頸定位流程），再擴充瓶頸所在的元件（9.6 容量規劃模型、9.15〈自動擴展（autoscaling）的反應時間與緩衝〉），或關掉非核心功能讓核心請求先過。瓶頸是單一 key 或分區時，擴充整個元件不會分散它的負載，那個 key 仍落在同一組節點上；應對是降低打到它的並行量，例如合併同一個 key 的重複讀取（request coalescing），或把 key 拆開。

請求失敗：抵達後被拒或失敗，與根本沒有抵達

請求失敗指一部分請求得到錯誤，其餘仍正常完成。它有兩種形態，監控上看到的地方完全不同。

請求抵達服務之後被拒或失敗。一種是服務主動拒絕：入口或後端依負載卸除或限流規則回 429 或 503，讓被拒的請求立即得到錯誤回應、其餘請求維持原本的延遲，這是設計負載卸除（Load Shedding）時刻意選擇的結果。另一種是資源耗盡造成的失敗：請求拿不到資料庫連線、等待到了上限而失敗，依賴的服務逾時，佇列已滿而寫不進去。拒絕也可能發生在後端之前：負載平衡器的佇列已滿時，請求到了負載平衡器而沒有到後端，由負載平衡器自己回 503 並計數（例如 AWS Classic Load Balancer 的 SpilloverCount），這些錯誤不在後端的錯誤率裡，要看負載平衡器的指標。

判斷標準是錯誤率在一段時間內超過門檻，主動拒絕與資源耗盡造成的失敗都算請求失敗。錯誤率除了算全體，也要依影響範圍（租戶、分區、端點）分開算：只佔總請求一小部分的範圍全部失敗時，全體的錯誤率仍然低於門檻。DynamoDB 2015 年 9 月的事故說明 寫到，主要問題在週日解決之後，殘留的整體錯誤率在 0.15% 到 0.25% 之間，部分客戶的錯誤率卻不成比例地高；隔天陸續有客戶開支援案件，AWS 寫到沒有及早察覺這個落差。要分開的是兩者的成因：429 是卸除與限流規則回的拒絕，503 則兩種成因都有，卸除規則與資源耗盡（例如等資料庫連線等到上限）都可能回 503。所以卸除與限流規則回的每一個拒絕，不論狀態碼是 429 還是 503，都在 log 欄位或指標標籤上標出拒絕它的規則，和其他 5xx 分開計算，才分得出拒絕是卸除在作用，還是服務本身出了錯。

請求根本沒有抵達服務。入口的網路頻寬塞滿、雲端主機超過每秒封包數的上限而默默丟包（9.4〈Resource saturation 的六個維度〉），這些請求不會進到後端程式；用戶端那一側看到的是封包重送之後的連線逾時，和無回應長得一樣。兩者的差別在入口記錄到的請求：沒有抵達時，入口的請求率比平常低；無回應時，請求照常抵達，進行中的請求數上升而完成的請求數下降。兩種情形下程序都還在執行，健康檢查不經過卡住的資源時也都成功，所以從程序與健康檢查分不出兩者。這些請求不在後端錯誤率的分子，也不在分母（分母是後端收到的請求總數，見 4.0〈應用層訊號：請求指標、log 與 trace〉）。判斷標準換成入口的請求率（每秒進來的請求數）比平常低，或從外面發出的探測失敗；這一篇說的「平常」都指同一時段的歷史值（例如上週同一天同一個小時）。主機網卡驅動的計數也看得到丟包（AWS ENA 在 ethtool -S 裡的 pps_allowance_exceeded、bw_in_allowance_exceeded）。

應對依形態而定。資源耗盡造成的失敗，先找出耗盡的是哪一種資源，見〈變慢之後走向哪一種結果：先耗盡的資源與等待是否設有上限〉；主動拒絕本身就是應對，要確認被拒的是低優先的請求（9.15〈負載卸除與限流的分工、請求的優先等級〉）；用戶端的重試會讓失敗的請求再送一次、加重負載，所以要配重試預算與退避（Retry Storm），寫入路徑的重試還要帶冪等鍵（見〈資料上的結果：重複寫入、接受後遺失與讀到舊資料〉）。沒有抵達的請求，服務端能做的有限，要在入口之前擴充頻寬或交給邊緣網路清洗（9.15〈體積型攻擊（DDoS）的處置：流量清洗與邊緣網路〉）。

無回應：程序還在，請求等到逾時也沒有結果

無回應指服務的程序仍在執行，而請求在用戶端設定的逾時之內等不到任何回應。判斷時用發出那個請求的用戶端自己的逾時：瀏覽器、上游服務與健康檢查各有各的逾時，健康檢查的逾時通常比較短，所以服務變慢時健康檢查可能先逾時：readiness 檢查（決定是否接流量）逾時，負載平衡器把實例移出；liveness 檢查（決定程序要不要重啟）逾時，平台重啟容器，見〈程序終止：被系統結束、當機或反覆重啟〉。健康檢查不經過卡住的那個資源（例如不查資料庫）時情形相反：轉址請求全部逾時，健康檢查仍然成功。無回應與請求失敗的差別在等待由哪一方結束：請求失敗是服務端在用戶端的逾時之前回了一個錯誤，無回應是用戶端的逾時先到、由用戶端自己放棄。

用戶端與服務之間有反向代理時，每一跳各自判一次：入口 Nginx 等後端等到 proxy_read_timeout（預設 60 秒）就回 504，後端連線被拒或連線被中途關閉時回 502。所以後端的無回應在瀏覽器那一側是 504 的請求失敗，後端的程序終止是 502；入口存取紀錄裡 502 與 504 的數量，是分辨後端這兩種結果的第一個訊號（各層逾時的大小關係見 Load Balancer 契約）。入口後面有多個後端實例時，Nginx 預設（proxy_next_upstream error timeout）會把 GET 這類冪等請求改送下一台，最終狀態碼可能是 200，每一次嘗試的狀態碼記在 $upstream_status，要從那個欄位數。

成因多半是沒有上限的等待：連線池、鎖或對依賴的呼叫沒有設逾時，每一個請求都卡在等待裡，執行緒或 goroutine 被佔滿之後，新的請求連被處理的機會都沒有。GC 壓力逐漸加重時，延遲緩慢爬升而請求仍然完成，呈現變慢（6.2 稱為逐漸退化型）；記憶體將滿、GC 連續執行時，程序大部分時間停在回收上，延遲超過發出請求那一方的逾時時就呈現無回應；記憶體繼續上升到上限就被 OOM 終止，所以同一次過載常是先無回應、再程序終止。

無回應會改變影響範圍。負載平衡器以健康檢查判斷實例能不能接流量，一台實例無回應時被移出，剩下的實例分到更多負載；9.15 無預警瞬時大流量 的〈負載卸除與限流的分工、請求的優先等級〉引用 Amazon 的說法，健康檢查回應不及時，機器被移出，機群因此變小。剩下的實例如果也接近各自的上限，多分到的負載會讓它們跟著進入無回應。

應對的第一步是由服務端替自己的等待加上限（Timeout、Deadline）：等資料庫連線、等鎖、等依賴回應都設上限，到上限就由服務端回錯誤，這個錯誤在用戶端的逾時之前送到，結果從無回應變成請求失敗。使用者得到錯誤而不是乾等，佔著的資源被釋放，健康檢查能在逾時內回應。加上限的同時，呼叫端的重試要受重試預算限制，否則逾時的請求會再送一次，成為停在失效的持續效應（Retry Storm）。依賴已經無回應時，用 Circuit Breaker 停止呼叫它，不再讓每一個請求等到逾時。重啟不改變負載：重啟回來的實例接到的負載和重啟前一樣，負載沒降下來時，它很快回到無回應。

程序終止：被系統結束、當機或反覆重啟

程序終止指服務的程序結束：被作業系統以記憶體不足（OOM）終止、遇到錯誤當機，接著被容器平台或 systemd 重啟，在負載沒有下降時一再重啟。在 Kubernetes 上，被 OOM 終止的容器終止原因記成 OOMKilled、退出碼 137，反覆重啟時狀態顯示 CrashLoopBackOff。

最常見的成因是記憶體。記憶體的佔用來自兩處：進行中的請求（請求與回應的物件、連線的緩衝區），排隊的請求越多佔得越多；以及服務持有的狀態（快取、session、監控後端的時間序列），隨狀態的數量成長。任一處到了上限，程序就被終止。

主機的記憶體耗盡時另有兩種走法。主機有 swap 時，記憶體耗盡先表現為大量換頁，整台主機的請求一起變慢到無回應，OOM killer 很晚才介入。主機層級的 OOM killer 依各程序用掉的記憶體（常駐記憶體加 swap）佔可用記憶體的比例評分，再加上 oom_score_adj，結束分數最高的程序；同一台主機上的資料庫或快取常駐記憶體大，常先被挑中，後端看到的是依賴失敗，也就是請求失敗（共用主機的資源爭用）。

另一個成因是平台的存活檢查：Kubernetes 的 liveness probe 連續逾時達到門檻時，kubelet 重啟容器；過載讓 probe 回應變慢，程序沒有壞也會被重啟，重啟期間其餘實例分到更多負載而跟著被重啟。終止原因沒有 OOMKilled、事件裡有 liveness probe 失敗，就是這一種。應對是讓 liveness 只檢查程序內部是否卡死、不經過依賴，逾時設得比過載時的延遲寬（Liveness、Liveness 與 Readiness〈探針靈敏度是雙向的取捨〉）。

重啟讓程序回來，而負載沒有變。重啟期間其他實例分到這一台的流量；重啟回來時程序內的快取是空的，原本由它回應的讀取全部打到資料庫，所以在負載下重啟常讓其他實例與資料庫跟著過載。應對依佔用的來源而定：進行中的請求佔掉的記憶體與進行中的請求數成正比，要限制進行中的請求數（上限可以固定，也可以依量到的延遲自動調整，即 adaptive concurrency limit）並卸除負載，讓重啟回來的程序不會再被推到記憶體上限；狀態佔掉的記憶體要限制狀態的數量（例如時間序列數的上限），限制進行中的請求數不會讓它下降。平台的自動重啟本身不會通知任何人，所以連續重啟要由一條告警看到（4.0〈容器與程序的自檢〉）。重啟回來的實例快取是空的，readiness 等快取預熱完成才回報就緒（Readiness、Cache Warmup），負載平衡器加回它時讓流量分段增加（slow start）。

尖峰過去或應對切換之後仍持續的情形：停在失效、擺盪與第二波湧入

變慢、請求失敗、無回應與程序終止，在負載下降之後通常會跟著消失；以下三種情形在尖峰過去、依賴恢復或應對切換之後仍然持續。

停在失效：觸發（流量尖峰、依賴故障、重新部署）已經消失、使用者發起的請求率回到平常，服務仍然大量逾時或出錯，原因是過載本身產生了額外的工作（重試、處理沒人在等的舊請求、快取變空之後改打資料庫的讀取），額外的工作又維持過載；這種讓過載自我維持的機制叫持續效應（sustaining effect），停在失效就是文獻裡的 Metastable Failure。9.15〈負載卸除與限流的分工、請求的優先等級〉描述的「過載因此變成穩定狀態」就是這一種。

停在失效的判斷標準是比對兩組數字：使用者發起的請求率（扣掉重試）已經回到平常，而每秒成功完成的請求數（goodput）沒有回到平常、錯誤率仍高；總請求率可能因為重試而高於平常，重試請求佔全部請求的比例也比平常高。瀏覽器的重新整理、入口反向代理的改送與多數自己寫的重試沒有標記，送到服務時和新請求長得一樣，所以扣掉重試的請求率要從入口分得出來的量取：不同使用者或工作階段的數量，或帶冪等鍵的請求以鍵去重後的數量；gRPC 的重試帶 grpc-previous-rpc-attempts，Envoy 開啟 include_request_attempt_count 後帶 x-envoy-attempt-count，有這些標記時可以直接扣掉。另外服務的資源要仍然飽和：等待連線的請求數、CPU 或資料庫讀取量高於平常；自己量得到的資源沒有飽和時，先看依賴回的錯誤，依賴的配額被重試用完時（第三方 API 回 429），飽和的是對方的配額，持續效應一樣存在（9.5 瓶頸定位流程〈逐層定位流程〉的外部 API 配額）。自己的資源沒有飽和、依賴也沒有回 429 時，goodput 低落的成因不是過載（例如資料庫切換後應用程式還連著舊的位址），要回到部署、設定與依賴的變更去找。

判斷之前還要排除觸發仍在的情形：依賴的錯誤率與延遲回到平常，被移出或終止的實例已經補回，部署已經完成或回滾。觸發是依賴故障或容量減少時，使用者的請求率可能一直在平常的範圍，請求率平常、goodput 低、資源飽和這三項在觸發仍在時同樣成立；那時是正在進行的過載，應對照它呈現的結果處理，並處理觸發本身（故障的依賴、減少的容量）。新部署的版本讓每個請求的成本變高時，三項也都成立而觸發仍在：處置是回滾；只把負載壓低再放回，放回之後每個請求仍然一樣貴，服務會再度過載。分辨的方法是看每個成功請求消耗的資源（每請求的 CPU 時間、每請求的資料庫查詢數）是否比觸發前高，而且高出的部分不是來自重試或快取未命中。

Slack 2021 年 1 月 4 日的事故可以拿來對照觸發仍在的過載：假期後第一個上班日流量上升，服務之間的託管網路元件（AWS Transit Gateway）來不及擴展而丟包，錯誤一直持續到網路恢復，那段期間要處理的是網路元件，不是持續效應。

確認是停在失效之後，應對是把負載壓到平常的量以下，讓持續效應停止（重試停下、舊請求清掉、快取預熱），佇列在過載時改成後進先出或依排隊時間丟棄，讓舊請求不再佔用處理時間，再逐步放回流量，做法見 Metastable Failure 卡。

非同步的消費端也會停在失效：入列速率回到平常，消費端成功處理的速率仍低於入列速率，落後量持續增加（Consumer Lag）；先進先出的佇列先處理已經過期的舊訊息時最容易這樣。

擺盪：卸除或擴縮的切換太快，服務在兩個狀態之間來回：卸除一啟動負載就下降，卸除解除後又過載；或擴充之後利用率下降、隨即縮減、延遲又超過門檻。9.15 引用 Stripe 的經驗寫到卸除削得太快會擺盪，擴展的觸發與縮回 以冷卻時間避免擴縮的抖動。應對是讓卸除與恢復都分段進行，擴縮設冷卻時間，縮減的門檻低於擴充的門檻，讓兩個切換點之間留出間隔。健康檢查也會造成擺盪：實例過載被移出，負載降下來後恢復、被加回，加回後又過載；應對是加回時讓流量分段增加（負載平衡器的 slow start），移出與加回用不同的連續次數門檻。

恢復時的第二波湧入：一個依賴故障期間，呼叫它的請求在用戶端或佇列裡累積；依賴恢復的那一刻，累積的請求與重試一起到達，讓剛恢復的依賴再過載一次（突發流量的分類 的〈不可預期突發〉）。第二波湧入本身是一次尖峰，累積的請求送完就結束；再過載之後如果重試維持住過載，就轉成停在失效。應對是讓累積的請求分散到達：用戶端的重試加退避與隨機延遲（jitter）、寫入的重試帶冪等鍵，Circuit Breaker 在半開狀態只放少量請求試探，佇列的消費端恢復後逐步提高消費速率，已經過了 deadline 的累積請求直接丟掉。

降級回應：回應成功而內容縮減

降級回應是應對選出來的結果，過載本身不會產生它：服務在過載時關掉推薦、回舊的快取資料、改成唯讀，回應照樣成功、延遲照樣正常。它把原本會走到請求失敗或無回應的情形，換成使用者拿得到、內容比較少的回應。使用者在過載期間拿到的是它，所以監控上也要分得出它（Degradation）。

延遲與錯誤率都看不到它，所以降級的程式路徑要自己計數：每一次回應走了哪一條降級路徑，記成一個計數指標，降級時才看得到有多少回應是縮減過的，以及降級在負載退去之後有沒有解除。降級也可能發生在服務之外：CDN 依 stale-if-error 在源站出錯時回舊內容（各家 CDN 的支援不同），這些回應要看 CDN 記錄裡的快取狀態（Stale-If-Error）。

資料上的結果：重複寫入、接受後遺失與讀到舊資料

變慢、請求失敗、無回應、程序終止與降級回應，是按使用者拿到的回應分類；過載在資料上另有三種結果，回應碼與延遲都看不出來。

重複寫入：寫入在用戶端放棄之後才完成，或服務端的 deadline 在資料庫已經提交之後才觸發，使用者拿到錯誤而寫入已經發生，用戶端重試就寫第二次。服務端替等待加上限（〈無回應〉的應對）會讓「回了錯誤而資料庫已經提交」更常發生，所以寫入路徑的重試要帶冪等鍵，服務端以鍵判斷是否已經處理過（Idempotency Key、接收方的重試決策）。訊號是同一個冪等鍵被重複送達的次數；還沒有冪等鍵時，訊號是業務上的重複（同一使用者、同一內容在短時間內寫進兩筆）。

接受後遺失：非同步路徑把事件放進程序內的緩衝就回應成功（API 回 202；短網址照常回轉址），程序被 OOM 終止時，緩衝裡還沒寫進佇列的事件跟著消失。短網址的點擊事件如果先放在後端程序內再批次寫入佇列，就是這一種。訊號是入口存取紀錄的請求數（或其他不在同一個程序裡的計數）與寫進佇列的事件數之間的差；接受數由同一個程序計數時，程序被終止的那一段會跟著消失。應對是讓回應在事件寫進持久的佇列之後才送出，或接受遺失並在統計上標明。

讀到舊資料：讀取走資料庫複本時，主庫的寫入量超過複本套用的速度，複寫延遲變長，剛建立的短網址從複本讀不到而回 404。錯誤率只算 5xx 時看不到它，延遲也正常；端點的 404 比例上升與複寫延遲是它的訊號，應對是剛寫入的資料從主庫讀，或讀取時帶上寫入的版本（Replication Lag、Read-After-Write）。

變慢之後走向哪一種結果：先耗盡的資源與等待是否設有上限

過載時，多數資源在耗盡前都先讓請求排隊，先出現的是變慢；入口頻寬與每秒封包數例外，超過上限的封包直接被丟掉。變慢持續下去會轉成哪一種結果，由最先耗盡的資源，以及等待那個資源時是否設有上限決定。先耗盡的資源指請求在這個服務裡等待的那一個；它的上游成因（例如服務之間的網路丟包）另外寫。下表是常見的對應：

先耗盡的是哪一個資源，看元件指標的飽和度（USE Method、9.5 瓶頸定位流程）；容器的 CPU 要看被暫停的時間（container_cpu_cfs_throttled_seconds_total，見 cgroup），只看主機的 CPU 會把它排除。CPU（含配額）與記憶體標為不適用，是因為等 CPU 的排程佇列與記憶體配置都沒有應用程式能設的等待上限。

同一個機制可以走到不同的結果。Queue 緩衝 寫的「goroutine 積壓 → 記憶體上升 → 最終 OOM 或 response timeout」就是兩條路：記憶體先到上限就是程序終止，用戶端的逾時先到就是無回應。9.14 連線池放大解法 的〈連線池放大的物理本質〉也是三種結果並存：記憶體耗盡而被 OOM 終止、行程切換變多而變慢、超過資料庫最大連線數而連線建立失敗。壓測時除了記下在多少負載越過 SLO，還要記下先耗盡的是哪一個資源、呈現的是哪一種結果，9.4〈Saturation 文件化：容量地圖〉的清單裡列了這一項。

影響範圍：從單一 key 到依賴與上游

結果之外，另一個要寫的是範圍：受影響的是一個 key 或分區、一個租戶、一個優先等級、一個端點、一個實例、同一台主機上的幾個服務、整個服務，還是已經擴散到依賴與呼叫它的上游（Cascading Failure、Blast Radius）。

範圍與結果會在時間上互相推動。一台實例無回應而被移出，剩下的實例負載上升，範圍從一個實例擴大到整個服務；後端無回應時，呼叫它的上游也在等待中耗盡自己的連線池，範圍擴散到上游。縮小範圍的手段是隔離：依租戶或功能分開資源池（Bulkhead）、依優先等級卸除，讓過載停在一個範圍裡。

觀察者自己也在範圍之內。監控程式與服務共用一個過載的資源時（同一台主機、同一段網路路徑、同一個資料庫），監控的抓取先逾時、資料先缺，判斷結果所需的訊號在最需要的時候先失真，見 4.27 主機過載時的監控告警。

各監控層看得到哪一種結果

服務端監控的分層（4.0）把監控分成自檢、服務網路內的探測、元件指標、應用層訊號、告警鏈的監看與合成監控等層，每一層看得到的結果不同：

表裡變慢（同步）與停在失效兩列的訊號要另外補。histogram 只量得到請求進到程式之後的時間，請求在入口或系統的佇列裡排隊的時間不在裡面，所以過載時應用層的延遲會低報，主機過載時的監控告警那一篇（4.27）改用從外面發的慢探測比例補上這一段。停在失效這一種沒有任何一層直接看得到，要另外寫一條比對規則：使用者發起的請求率已經回到平常的範圍、依賴與容量已經恢復，而 goodput 仍低於平常、元件指標的飽和度高於平常，而且 goodput 在這段時間內沒有上升趨勢（快取逐漸回熱、goodput 一路上升的是自己在恢復），持續一段時間就送出。另外，程序終止那一列的 node_systemd_service_restart_total 由 node_exporter 的 systemd collector 產生，那個 collector 預設關閉，重啟計數另有開關（--collector.systemd.enable-restarts-metrics），沒開過的主機上查不到這個指標。

描述一次過載時要寫出的內容

壓測報告、事故紀錄與容量地圖描述一次過載時，「撐不住」只說了有一個上限被越過，讀的人不知道使用者看到什麼、哪一個資源先用完、該用哪一種應對。改寫成五項：負載量與它的量法（每秒多少請求、哪一種請求組合、每個請求的大小或工作量）、呈現的結果（使用者拿到的是變慢、請求失敗、無回應、程序終止還是降級回應；觸發消失之後是否仍然持續，是停在失效、擺盪還是第二波湧入；資料上有沒有重複寫入、接受後遺失或讀到舊資料）、先耗盡的資源、影響範圍、監控從哪一層看到。例如：「每秒轉址請求超過壓測的上限之後，資料庫連線池先耗盡，連線池設了等待上限，所以呈現的是約一成的轉址請求失敗（503），其餘延遲不變；應用層的錯誤率告警先送出，健康檢查一直正常。」（這個例子的數字是示意。）實際記錄時，數字取自壓測或事故本身並寫明出處。

延伸閱讀：飽和曲線、應對手段與監控層

• 負載在飽和曲線上的位置、knee 與 cliff 的量法、容量地圖：9.4 Saturation Discovery
• 沿著請求路徑分析負載時共用的概念（一次一筆的處理與互斥範圍、可提早回應的比例、保護把負載轉到哪裡、保護元件故障時的處置）：9.0 請求路徑上的負載分析
• 負載卸除、准入控制、重試預算、擴展跟不上時的退路：9.15 無預警瞬時大流量
• 熱點列與連線池的耗盡順序、等待上限與呼叫方逾時的關係，在售票系統上的完整例子：9.0.1 售票搶購的負載路徑；請求晚一點處理就失去價值、過載時要明確拒絕的撮合系統：9.0.2 交易撮合的負載路徑
• 監控各層的做法、各層看不到的範圍與接手的層：4.0 服務端監控的分層
• 可用性與延遲分成兩個告警、過載時監控自身的失真：4.27 主機過載時的監控告警
• 負載退去之後仍停在失效狀態的機制與脫離方式：Metastable Failure

概念位置

同一個服務平常處理得了的負載，在 metastable failure 期間處理不了，因為服務做的工作比進來的請求多。常見的持續效應：用戶端的重試讓同一個請求被送好幾次（Retry Storm）；伺服器繼續處理已經逾時、沒有人在等結果的舊請求，佔掉處理新請求的資源；快取在故障或重啟後變空，原本由快取擋下的讀取全部打到資料庫（Cache Warmup）；過載造成的 GC、鎖競爭或 leader 反覆選舉，讓服務每秒處理得了的請求變少。Google《Site Reliability Engineering》的〈Addressing Cascading Failures〉舉的例子是一個在每秒一萬個請求下健康的服務，到每秒一萬一千時因當機開始連鎖失效；把負載降到每秒九千幾乎止不住當機，因為需求集中到剩下的少數伺服器上，假設只剩一成伺服器健康，要降到約每秒一千才能穩定並恢復；同一章也寫到，重試會讓後端在原始的請求率下降之後仍然過載，要大幅降低前端送進來的負載直到重試停止。

可觀察訊號與例子

判斷的依據是比對兩組數字：使用者發起的請求率（扣掉重試）已經回到平常的量，而每秒成功完成的請求數（goodput）或錯誤率仍沒有回到平常；總請求率可能因為重試而高於平常。另外兩個訊號是重試流量佔總請求的比例偏高，以及資料庫的讀取量明顯高於平常的同一時段（快取還沒熱）。短網址服務在一次資料庫切換之後，轉址請求的總量回到平常，成功的轉址卻只有平常的一半，log 裡同一個使用者在幾秒內重複送出同一個請求的紀錄大量出現，就是這個樣子（例子的數字是示意）。

判讀方式

流量回到平常而服務仍不恢復時，先確認觸發已經消失：依賴的錯誤率與延遲回到平常、被移出的實例已經補回、新部署的版本已經回滾或確認每個請求的成本沒有變高；觸發是依賴故障或容量減少時，請求率從頭到尾都在平常的範圍，觸發仍在的過載，在請求率、goodput 與資源飽和度上和 metastable failure 一樣。再確認資源仍然飽和（等待連線的請求數、CPU 或資料庫讀取量高於平常），或依賴的配額被重試用完而回 429；自己的資源沒有飽和、依賴也沒有回 429 時，成因不是過載，要回到部署、設定與依賴的變更去找。資源飽和時要處理的是持續效應：等流量自己退不會讓服務恢復，加容量要加到能消化重試與舊請求帶來的額外工作才有效。脫離 metastable failure 要拿掉持續效應：把進入服務的負載壓到平常的量以下（負載卸除、准入控制）、讓用戶端停止重試或拉長退避、丟掉已經逾時的排隊請求、先預熱快取再恢復全部流量。預防的做法是在平常就限制持續效應：重試預算、有上限的佇列與逾時、依優先等級卸除。負載超過容量時服務呈現的各種結果與各自的判斷標準，見 9.16 負載超過容量時服務的表現；卸除與准入的做法見 9.15 無預警瞬時大流量。