+− THE DAILY DIFFdev & AI news
SHIP IT

當回應消失時,Stripe 會記住你的請求

伺服器完成操作後,逾時可能會使結帳作業不確定。

伺服器完成操作後,逾時可能會使結帳作業不確定。本篇《深入解析》使用 Stripe API v1 記錄的冪等性協定,展示了穩定的操作金鑰、儲存的回應重播、參數和並行限制、保留期限和結果協調。

閱讀書面版(英文) ↗

本影片重點

  • 冪等性關乎重複操作的預期效果。Stripe API v1 新增了文件化的儲存回應重播協定。
  • 同一邏輯動作的重試使用相同的金鑰和參數。跨獨立的 SDK 呼叫或應用程式重新啟動時,請保留操作金鑰;一個真正新的動作需要自己的金鑰。
  • 端點執行開始後,Stripe API v1 會儲存第一個請求的狀態和主體,包括 500 錯誤,並在重試時返回該儲存的回應。
  • 相同金鑰但參數變更會產生不符。驗證失敗和並行執行衝突不會為該嘗試儲存冪等結果,可以重試。
  • Stripe 會將 API v1 金鑰保留至少 24 小時,之後可能會修剪。將未解決的網路重試限制在前 24 小時內,然後停止並在重複操作之前進行協調。
  • 在連線恢復後,緩存的 500 錯誤可能會持續重播。原始操作可能產生副作用;請使用相關物件、儀表板請求和網路掛鉤來確定其結果。
  • API v2 使用不同的重播語義。金鑰不會為電子郵件、庫存和每個本地資料庫操作建立通用的「精確一次」交付。

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

逾時會取消你的付款嗎?

0:00 你認為逾時意味著你的付款失敗了。 伺服器可能在回覆消失時完成, 讓你的結帳畫面自信地顯示著什麼都沒有。 為什麼重試會再次收費? Stripe 如何記住一次嘗試? 你應該什麼時候停止重試? 並記住一個討厭的細節。 一個被記住的錯誤可能比網路問題持續更久。

0:17 我們稍後會再討論。 這裡是 The Daily Diff,深入解析。

冪等性金鑰識別什麼?

0:21 冪等性意味著重複一個操作與執行它一次具有相同的預期效果。 冪等性金鑰標記一個邏輯動作。 Stripe 的 API 版本一在重試時識別該標籤並重播一個儲存的回應。 想像一下買一杯咖啡。 Stripe 完成了你的支付請求,並且回應在返回時丟失了。 客戶看到了旋轉圖示。 他們的銀行可能有更令人興奮的解釋。 一個未受保護的建立請求可能會重複副作用。

同一個金鑰如何讓重試安全?

0:45 在第一次嘗試之前附加一個唯一金鑰並在重試時保留它。 如果你的應用程式重新啟動,請在你的記錄中保留該金鑰及其操作。 對於 Stripe 的版本一 API,一旦端點執行開始, 第一個請求的狀態和主體就會被儲存。 再次發送相同的金鑰和參數,Stripe 將返回儲存的回應。 咖啡不動,而收據再次傳送。

Stripe 到底儲存了什麼?

1:07 這是 Stripe 的實際措辭。 帶有相同金鑰的重試會返回儲存的回應, 包括五百錯誤。 文件比你樂觀命名的重試輔助程式做得更多。 客戶再次點擊。 你的應用程式決定這是恢復待處理的購買還是開始另一個。 一個真正的新咖啡會獲得一個新金鑰。 為每個網路重試使用新金鑰會破壞保護。

1:27 相同金鑰但參數不同會觸發不符。

當請求變更時會發生什麼?

1:30 如果參數驗證失敗,或帶有該金鑰的另一個請求仍在 執行中,Stripe 不會為該嘗試儲存冪等結果。 這些請求可以重試。 競速請求會產生衝突。 這些是版本一的規則。 版本二的行為不同。 一個標頭無法保證你的系統中精確一次的交付。 電子郵件、庫存和你的資料庫都需要故障處理。

1:52 金鑰在文件化的範圍內保護操作。 Stripe 會將版本一金鑰保留至少二十四小時,之後可能會修剪。

已記住的結果重試安全期是多久?

1:59 修剪後的金鑰可以執行一個新請求。 將未解決的重試保持在第一天內。 在此之後,停止並協調原始結果。 使用指數退避和抖動來給伺服器喘息空間。 否則重試會在一家著火的咖啡店外排隊。 Stripe 的函式庫處理重試,但請檢查你的函式庫的預設值。 那個惱人的錯誤就是問題所在。

為什麼已記住的錯誤會一直出現?

2:20 緩存的五百回應在連線恢復後會持續重播。 原始操作可能已產生副作用。 使用物件、儀表板和網路掛鉤來解決其結果。 一個新金鑰可以重複該動作。 如果你寧願閱讀而不是聽我說,The Daily Diff 會每天早上免費發送到你的收件箱,網址是 the daily diff dot dev,連結如下。 每天早上免費發送到你的收件箱,網址是 the daily diff dot dev,連結如下。

我會使用這個協定來發布重試按鈕嗎?

2:39 結論,深入解析。 發布。我會發布帶有有限重試和協調的穩定金鑰, 這樣客戶就可以喝到咖啡,而無需資助你的分散式系統教育。 這就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 負責任地合併。

來源

  1. Idempotent requestsStripe Docs
  2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
  3. Advanced error handlingStripe Docs
  4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor

相關影片

under-the-hood · zh-TW · 2026年9月24日

SAML,內部構造:信件中的簽章

SAML 讓您登入幾乎所有工作應用程式,其簽章存在於它簽署的 XML 內部。深入探討:應用程式、瀏覽器和身分提供者之間的登入過程,斷言的樣子,為什麼規範化必須在每個位元組上達成一致,以及為什麼從 2012 年到 2025 年,相同的錯誤類別不斷重現。受 Trail of Bits 的「SAML:糟糕設計的碎形」(在 Hacker News 上獲得 312 點) 啟發。

3:02 ↗
under-the-hood · zh-TW · 2026年9月23日

模型終止運作的幕後故事

AI 模型並非「死亡」——它會收到一個終止日期,隔天早上,您的 API 呼叫會回傳 404:「該模型已棄用,請點此了解更多。」幕後故事:四種狀態的流程(活躍 → 舊版 → 棄用 → 退役),通知期限(OpenAI:一般模型 ≥ 6 個月/3 個月,預覽版約 2 週;Anthropic ≥ 60 天),開發者會遇到的問題(響亮的 404、無聲的評估漂移、Claude 4.7+ 溫度參數導致的新 40

3:15 ↗