一個缺失的併發限制讓 Bluesky 半數使用者中斷服務八小時

2026 年 4 月 4 日星期六，Bluesky 的 AppView 資料平面——為社交應用程式提供讀取服務的後端——開始記錄諸如「failed to set post cache item: dial tcp: bind: address already in use」的錯誤。該資料平面大量依賴 memcached 來減輕主 Scylla 資料庫的負載，而值班的基礎設施工程師 Jim Calabro 發現日誌尖峰與使用者可見流量的下滑相互吻合。網路監控一切正常，因此整個週末服務雖勉強運作，原因卻始終隱而未現。

根本原因是當週部署的一個新內部服務：每秒不到三次 GetPostRecord 請求，但每批包含 15,000–20,000 個貼文 URI（正常為 1 到 50 個）。每個資料平面的 RPC 處理常式都以 errgroup.SetLimit 限制併發——唯獨這個端點缺少了那一行。單次呼叫就產生多達 20,000 個 goroutine，撥出大量 memcached 連線；一旦 1,000 個 socket 的空閒池溢出，它們便堆積在 TCP TIME_WAIT 中，耗盡所有臨時連接埠。該用戶端只在一個資料中心執行，且由於沒有依用戶端區分的指標，各類型的快取錯誤掩蓋了元凶。

到了 4 月 6 日星期一，情況急轉直下陷入死亡螺旋：每秒有數百萬個 memcached 請求失敗，而 Bluesky 的「記錄每個錯誤」政策試圖每秒執行數百萬次阻塞式 write(2) 日誌寫入。阻塞式系統呼叫的洪流使 Go 執行環境從約 150 個 OS 執行緒暴增到 1,500 個，導致 GC 飢餓並陷入長時間的 stop-the-world 暫停。激進調校的 GOGC 與 GOMEMLIMIT 使資料平面週期性地 OOM 當機——運作約 30 分鐘後就掛掉，然後重啟，如此反覆。每次重啟都讓情況更糟：TIME_WAIT socket 使重啟後的行程無法重建其 memcached 連線池。

星期一的權宜之計荒謬得令人莞爾：一個自訂撥號器，為每個對外連線隨機挑選一個 127.x.y.z 迴路 IP，將 ip+port 空間擴展到超出已耗盡的範圍。這止住了螺旋，而團隊直到星期三才找到真正的根本原因，並還原了缺失的 SetLimit(50)。Calabro 的公開事後檢討也承認了一次溝通失誤：狀態頁面將問題歸咎於第三方網路供應商，而「顯然並非如此」。

2026 年 4 月 6 日約八小時內，約半數 Bluesky 使用者經歷間歇性中斷——這是該平台基礎設施負責人在職期間最嚴重的一次故障

有界併發是靠慣例而非結構來強制執行：每個處理常式都有 SetLimit，唯獨一個沒有，而單一無界端點就足以耗盡主機層級的資源。

流量契約沒有形狀限制：沒有任何機制拒絕 20,000 個項目的批次，因此一個安靜的內部用戶端——每秒 3 次請求——作為負載來源竟壓過了數百萬個正常用戶端。

故障處理放大了故障：每秒記錄數百萬個 memcached 錯誤，將快取問題轉變成執行緒暴增、GC 暫停與 OOM 當機。

可觀測性假設請求都很小，且沒有依用戶端區分的指標，因此各類快取錯誤掩蓋了應負責的那一個呼叫方與那一個端點，持續數日。

以重啟作為復原手段失效了：已死行程遺留的 TIME_WAIT socket 阻擋了新行程重建其 memcached 連線池，使 OOM 重啟演變成更多的連接埠耗盡。

一個無界的 goroutine 迴圈壓過了所有其他防護措施。併發限制必須是結構性的，而非每個端點各自的習慣：唯一缺少限制的那個端點，就成了整起事件。

服務於星期一以隨機迴路撥號器穩定下來，該撥號器在真正的修正——還原併發限制——於 4 月 8 日星期三上線後被移除。總計約八小時的間歇性中斷，影響約半數使用者。這份於 2026 年 4 月 10 日發布的事後檢討承諾提供依用戶端區分的可觀測性、偵測送出少量超大請求的用戶端，並從大量日誌轉向 Prometheus 指標與 OpenTelemetry 追蹤；兩天後，可靠性研究者 Lorin Hochstein 對此發表了一份詳盡的獨立分析。