1、冪等性定義

HTTP協議涉及到的一種重要性質：冪等性(Idempotence)。在HTTP/1.1規范中冪等性的定義是：

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

從定義上看，HTTP方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。

實際上，冪等性是分布式系統設計中十分重要的概念，而HTTP的分布式本質也決定了它在HTTP中具有重要地位。

2、HTTP請求方法的冪等性

假如在不考慮諸如錯誤或者過期等問題的情況下，若干次請求的副作用與單次請求相同或者根本沒有副作用，那么這些請求方法就能夠被視作 “冪等” 的。

HTTP 方法中：

• GET 方法用于獲取資源，不會影響到資源的變化，所以是冪等的。
• HEAD 方法向服務器索要與GET請求相一致的響應，只不過響應體將不會被返回，所以是冪等的。
• PUT 方法表示更新資源，而PUT所對應的URI是要創建或更新的資源本身，對同一URI進行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有冪等性。
• DELETE 方法用于刪除資源，有副作用，但它應該滿足冪等性。
• OPTIONS 方法返回服務器針對特定資源所支持的HTTP請求方法，所以是冪等的。
• TRACE 方法可以回顯服務器收到的請求，主要用于測試或診斷，所以是冪等的。
• POST 方法表示創建資源，兩次相同的POST請求會在服務器端創建兩份資源，它們具有不同的URI，所以不具備冪等性。

假如某個由若干個請求做成的請求串行產生的結果在重復執行這個請求串行或者其中任何一個或多個請求后仍沒有發生變化，則這個請求串行便是“冪等” 的。但是，可能出現若干個請求做成的請求串行是“非冪等”的，即使這個請求串行中所有執行的請求方法都是冪等的。例如，這個請求串行的結果依賴于某個會在下次執行這個串行的過程中被修改的變量。

3、分布式事務 vs 冪等設計

（1）示例

假設訂單支付過程，如果操作成功，則賬戶余額減少對應的金額；如果操作成功，則賬戶余額不變。
如果用戶重復多次點擊支付按鈕，或者是網絡異常導致訂單已經支付成功了但沒有及時反饋給用戶，用戶再次點擊支付按鈕，就可能造成重復扣款，造成嚴重后果。

這個問題的解決方案：采用分布式事務，冪等設計

（2）分布式事務

通過引入支持分布式事務的中間件來保證支付功能的事務性。

分布式事務的優點是對于調用者很簡單，復雜性都交給了中間件來管理。缺點則是一方面架構太重量級，容易被綁在特定的中間件上，不利于異構系統的集成；另一方面分布式事務雖然能保證事務的ACID性質，而但卻無法提供性能和可用性的保證。

（3）冪等設計

服務器端生成的唯一的處理號，將它用于標識后續的操作，一個處理號表示的操作至多只會被處理一次，每次調用都將返回第一次調用時的處理結果，這樣就符合冪等性。

冪等設計是一種更輕量級的解決方案，容易適應異構環境，以及性能和可用性方面。在某些性能要求比較高的應用，冪等設計往往是唯一的選擇。

總結

以上是生活随笔為你收集整理的幂等性（HTTP）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。