冪等性總結
HTTP/1.1中對冪等性的定義是：一次和多次請求某一個資源對於資源本身應該具有同樣的結果（網絡超時等問題除外）。
- 也就是說，其任意多次執行對資源本身所產生的影響均與一次執行的影響相同。
這裏需要關注幾個重點：
- 冪等不僅僅只是一次（或多次）請求對資源沒有副作用（比如查詢數據庫操作，沒有增刪改，因此沒有對數據庫有任何影響）。
- 冪等還包括第一次請求的時候對資源產生了副作用，但是以後的多次請求都不會再對資源產生副作用。
- 冪等關注的是以後的多次請求是否對資源產生的副作用，而不關注結果。
- 網絡超時等問題，不是冪等的討論範圍。
- 冪等性是系統服務對外一種承諾（而不是實現），承諾只要調用接口成功，外部多次調用對系統的影響是一致的。聲明爲冪等的服務會認爲外部調用失敗是常態，並且失敗之後必然會有重試。
冪等的不足
冪等是爲了簡化客戶端邏輯處理，卻增加了服務提供者的邏輯和成本，是否有必要，需要根據具體場景具體分析，因此除了業務上的特殊要求外，儘量不提供冪等的接口。
- 增加了額外控制冪等的業務邏輯，複雜化了業務功能；
- 把並行執行的功能改爲串行執行，降低了執行效率。
保證冪等策略
冪等需要通過唯一的業務單號來保證。也就是說相同的業務單號，認爲是同一筆業務。使用這個唯一的業務單號來確保，後面多次的相同的業務單號的處理邏輯和執行效果是一致的。 下面以支付爲例，在不考慮併發的情況下，實現冪等很簡單：①先查詢一下訂單是否已經支付過，②如果已經支付過，則返回支付成功；如果沒有支付，進行支付流程，修改訂單狀態爲‘已支付’。
防重複提交策略
上述的保證冪等方案是分成兩步的，第②步依賴第①步的查詢結果，無法保證原子性的。在高併發下就會出現下面的情況：第二次請求在第一次請求第②步訂單狀態還沒有修改爲‘已支付狀態’的情況下到來。既然得出了這個結論，餘下的問題也就變得簡單：把查詢和變更狀態操作加鎖，將並行操作改爲串行操作。
樂觀鎖
如果只是更新已有的數據，沒有必要對業務進行加鎖，設計表結構時使用樂觀鎖，這樣既能保證執行效率，又能保證冪等。