什麼是冪等？
在電腦科學中，冪等是指某項作業的特性，即多次套用該作業的最終效果與只套用一次相同。如果對伺服器傳送相同要求五次，冪等系統會確保伺服器上的結果在第一次成功嘗試後不會變更。
除了確保結果相同，冪等作業的重要特徵是，額外呼叫不會產生副作用。這是建構具備韌性的分散式系統的基本要求，因為間歇性網路中斷或逾時可能會導致用戶端多次傳送相同的訊息。
瞭解如何在 Cloud Run 編寫冪等函式
比喻：這就像電梯的「向上」按鈕。按一下按鈕，電梯就會來到您所在的樓層。即使您等待時又按了十次，結果還是一樣，只會有一部電梯來到您的樓層。多次按下按鈕並不會召喚十部不同的電梯。反之，將商品加入數位購物車通常不是冪等。如果按五次「加入購物車」按鈕，購物籃中很可能就會有五件相同商品。
冪等系統的主要優點
在不穩定的網路中確保可靠性
在逾時或連線中斷後，安全地重試要求，不必擔心重複執行動作 (例如重複向信用卡扣款)。
簡化使用者邏輯
使用者不必追蹤複雜的狀態，就能知道先前的要求是否成功，只要「重試直到成功」即可。
基礎架構韌性
分散式系統可透過重播記錄或重新傳送遺漏的訊息，從當機中復原，且不會損毀資料。
冪等與非冪等 HTTP 方法
REST 標準定義了不同類型的網路要求應如何運作。有些 HTTP 方法的設計在本質上具備「安全」或冪等的特性，這代表根據規格定義，即使多次重複執行，這些方法的行為依然可預測。有些方法會建立新資料，因此重試時必須格外謹慎，確保安全無虞。
冪等方法 (GET、PUT、DELETE)
根據 RFC 9110，有幾種標準方法本質上是冪等。重複執行這些動作，伺服器的狀態不應超出初始要求。
- GET：這個方法會擷取資料。由於不會變更伺服器上的任何內容，因此您可以呼叫一百萬次，資源仍會保持不變。
- PUT：這個方法會完全取代資源。如果將使用者的電子郵件地址更新為「user@example.com」三次，最終狀態仍是「user@example.com」。
- DELETE：這會移除資源。如果刪除「訂單 #123」後再次嘗試刪除，該訂單仍會維持刪除狀態。結果 (訂單消失) 仍相同。
非冪等方法 (POST、PATCH)
部分方法並非冪等，因為其主要工作是變更資料，以建立新內容或修改現有記錄的一部分。
- POST：開發人員使用 POST 建立新資源。如果沒有冪等邏輯，重複傳送相同的 POST 要求 (例如「提交付款」)，通常會產生兩筆獨立記錄，並向客戶收取兩次費用。
- PATCH：這個方法會套用部分更新。雖然可以設為冪等，但預設通常不是，因為重複相對變化 (例如「餘額加 5」) 會導致每次呼叫後的最終值不同。
如何導入冪等 API
- 產生專屬金鑰：用戶端建立專屬字串 (例如 UUID)，並將其納入自訂 HTTP 標頭。
- 攔截並驗證：伺服器會檢查 Memorystore 等高速資料儲存庫，確認該金鑰是否最近已經過處理。
- 處理狀態：如果金鑰是新的，則處理要求並儲存結果。如果金鑰重複，則立即傳回儲存的結果，不必重新執行商業邏輯。
冪等的常見用途
我們建構的系統通常需要具備冪等。在某些情況下，系統會自動為我們處理。在其他情況下，開發人員需要採取行動才能實現。
付款處理
最著名的例子是「重複收費」問題。如果使用者在支付機票費用時，瀏覽器停止回應，可能會再次點選「付款」。使用冪等鍵的付款 API 會確保將第二次點擊視為重試。這項功能可保護客戶的銀行帳戶，並降低處理重複交易退款的營運成本。
- 開發人員必須採取行動：在 API 要求中導入冪等鍵 (通常是 UUID)，確保將第二次點擊視為重試，以保護客戶的銀行帳戶
基礎架構即程式碼 (IaC)
Terraform 和 Ansible 等工具都仰賴冪等。當您執行「建立 10 GB 儲存空間 bucket」的指令碼時，這類工具會檢查雲端目前的狀態。
- 自動處理：冪等由 IaC 工具本身管理，開發人員不必編寫額外邏輯來防止資源重複
API 開發 (REST)
現代網路 API 通常會實作 Idempotency-Key 標頭 (現為標準化網際網路工程任務組 (IETF) 草稿)，讓開發人員能建構更穩固的整合。
- 開發人員必須採取行動：建構後端時，您必須實作邏輯來攔截這些鍵、檢查先前的嘗試，並傳回快取的回應
資料庫新增或更新
「upsert」(新增或更新) 是經典的冪等資料庫作業。「新增或更新」並非單純的「插入」，而是「如果記錄存在，就更新；如果不存在，就建立」。
- 自動處理：資料庫引擎會以原生方式處理這項邏輯，確保無論指令碼執行多少次，記錄都會收斂至正確的狀態
