1.對每次請求生成請求id，進行防重複，redis或者應用內快取防重

2.很多請求本身就是冪等的，比如update指定的where條件，加版本樂觀鎖

冪等性的概念

使用者同一操作請求了一次或者多次，最終的結果應該是一致的，並不會因為多次請求產生副作用；冪等操作的特點是“多次執行所產生的結果與一次執行的結果相同”。比如：

付款操作的時候，請求已經發送給服務端，但是由於網路原因未收到付款結果（實際上已成功），再次操作付款的時候，不應該成功；

新增和修改，如果不做冪等性處理，可能就會產生問題（如果修改只是把某些欄位更新成固定的值，不會有冪等性問題，但是如果新值要在舊值上做處理做計算，如增加多少、減少多少，那麼多次執行的結果就會有差異）；那麼保證冪等性有哪些方案呢？（給出我知道的方案，方案有好有壞）

悲觀鎖：獲取資料的時候加鎖獲取；select * from table where col="xxx" for update; 只能說是一種實現方案，但是不是特別好；

樂觀鎖：在更新資料那一刻鎖表，可以透過條件限制，也可以透過版本號來實現，比如：資料中增加版本號的概念，那麼在做資料修改，把當前資料的版本號帶上，修改的時候要按照版本號判斷資料是否發生過更改。如果沒有發生過更改，則執行業務操作，並更新版本號。

分散式鎖：在業務系統執行插入或更新操作的時候，先要獲取分散式鎖，然後做操作，之後釋放鎖；分散式鎖保證在一個時間內，只會有一個執行緒對資料進行操作；

全域性唯一請求ID：每一次的請求，都帶有一個全域性唯一的請求ID，這個請求ID只要執行過一次就失效了：

狀態冪等：如果業務流程中的每個階段，資料都有不同的狀態，那麼當資料已經處於下一個狀態的時候，這時候又來了上一個狀態的變更，是不會執行成功的（其實有些類似於版本號的概念，不過這個狀態是有業務含義的）。

1 冪等含義

操作一次和操作多次結果一致被稱為冪等。下面我們來分析幾種常用冪等方案。

場景：使用者支付成功（訂單ID=aaa）此時支付系統將支付成功的訊息，傳送至訊息佇列。物流系統訂閱到這個訊息，準備為這筆訂單建立物流單。

但是訊息佇列有可能會重複推送，也就是說物流系統有可能接收到多次這條訊息。我們希望達到的效果是：無論接收到多少條重複訊息，只能建立一筆物流單。

方案：新建一張冪等表，該表就是用來做冪等的，無其它業務意義。該表有一個欄位名為key，建有唯一索引，這個欄位是冪等的標準。

當物流系統訂閱到訊息後，在建立物流單前，首先要將訂單ID（本例=aaa）嘗試插入冪等表的key欄位。如果插入成功則繼續做業務。不成功表示已經處理過了，丟棄訊息。

這張表所有業務都可以操作，資料量會很大，需要定期清理，並將資料備份。

當然可以利用分散式鎖鎖住訂單ID，判斷是否已經有物流訂單了，沒有就建立物流訂單。這種方法本質上是在解決併發問題。

場景：物流單處理成功，傳送訊息給訂單系統，讓訂單更新狀態為完成，假設操作是將訂單status=0更新至status=1。同理訂單系統也可能收到多條訊息。

方案：使用狀態機方案：status=0只能流轉至status=1轉態，並且status=1已經是最終態。當訂單為status=1時，即使接收到物流單成功的訊息也不在處理，丟棄訊息。

(1) 先查出資料，資料中包含欄位version

(2) 傳送業務操作更新語句：update xxx set xxx,version = #{version} + 1 where id = #{id} and version = #{version}

(3) 如果此時該記錄已經被修改，version就已經發生了變化，不能被更新成功