你的重試迴路假設第一次請求失敗了。它大概沒有。
超時或當機不代表你的 API 請求遺失了。以下是 idempotency keys 如何讓重試變得安全，以及真正能防止重複的儲存模式。
你的服務在處理 請求到一半時當機了。客戶端看到超時並重試。現在你有兩筆扣款。客戶很生氣。資料庫是一致的。你的商業邏輯不是。 這不是邊緣案例。這是分散式系統的預設行為。網路會丟封包。container 會在請求處理到一半時被 OOM-killed。負載平衡器會對已經抵達後端的請求回傳 502。如果你的 API…
resilience
4 posts
比你的进程更長命的 lock：分散式租約的實際運作原理
記憶體中的mutex會在伺服器重啟後消失。本文說明具有 fencing token 與 TTL 的分散式租約如何防止當機後的重複執行，以及它們仍然會失效的地方。
你的 撐不過 。它也撐不過 OOM、部署推出或節點重啟。程序結束的瞬間，lock 就消失了。如果那把 lock保護的是一個排程任務、資料遷移或領導者選舉，你現在會有兩個程序都認為自己是唯一在執行的那個。 這不是你的mutex有 bug。這是類別錯誤。程序本地的lock無法保護叢集範圍的資源。…
沒有 goroutine、沒有 timer、也沒有背景開銷的斷路器
大多數斷路器函式庫會產生背景執行緒來探測恢復狀態。你並不需要它們。這裡介紹一種由請求驅動的設計，能在不犧牲正確性的前提下，消除所有背景開銷。
我審閱過的每一個 production 級斷路器，最終都會產生一個背景執行緒。它可能是 Go 的 goroutine、Java 的 ，或是 Rust 的 tokio task。工作內容永遠一樣：每隔幾秒醒來一次，檢查下游服務是否已恢復，然後從 OPEN 切換回 CLOSED。…
你的 Web Service 有一條 Graceful Shutdown 路徑。那就是 Bug。
Crash-only software 把每一次失敗都當成 crash，把每一次啟動都當成 recovery。對 Web Service 來說，這意味著刪掉你的 shutdown 邏輯，並設計出能撐過 kill -9 的狀態。
你的 Web Service 有一個 shutdown handler。它會 flush buffer、關閉連線、寫入 checkpoint。你也許測試過一次。在生產環境，它大概一年只在計畫性部署時執行一次。其他時候，你的服務死於 OOM kill、node eviction、斷電，或是部署超時後被 SIGKILL。…