舉個具體例子，假如你是買東西生成訂單，按道理用戶一次只能生成一個訂單；但是有時候由于網(wǎng)絡(luò)原因什么的，用戶連續(xù)點了多次，那這個時候不能說就給人家生成好幾份訂單，所以在生成訂單的時候，用冪等去保證只生成一份。其實往網(wǎng)絡(luò)上面去說，一個請求可能由于網(wǎng)絡(luò)原因發(fā)送了兩次，但是這些信息只需要被處理一次，這時候就需要冪等去保證只處理一次。

將每一個不同的業(yè)務(wù)操作賦予其唯一性。這個唯一性是通過對不同操作所對應(yīng)的唯一的內(nèi)容特性生成一個唯一的全局ID來實現(xiàn)的?；驹瓌t為：相同的操作生成相同的全局ID；不同的操作生成不同的全局ID。生成的全局ID需要存儲在Redis中，
其相應(yīng)的key和value如下：
key：將對于不同的業(yè)務(wù)，采用APP_KEY+業(yè)務(wù)操作內(nèi)容特性生成一個唯一標(biāo)識trans_contents。然后對唯一標(biāo)識進行加密生成全局ID作為Key。
value：current_timestamp + trans_contents，current_timestamp用于標(biāo)識當(dāng)前的操作線程。
判斷是否重復(fù)，主要利用redis的SETNX方法，如果原來沒有值則set且返回成功，如果已經(jīng)有值則返回失敗.

最簡單的方案，給每次請求生成相同的唯一key，把這個key丟到分布式緩存里，每次請求過來判斷下這個key存不存在就可以了

服務(wù)器給一個sid（作用類似于預(yù)生成一個id），客戶端發(fā)起請求時都帶著這個sid，服務(wù)器檢測到相同的有效sid，則返回第一次請求的結(jié)果，防止各種原因發(fā)生的重復(fù)請求。就像樓上說的下訂單。對于sid的策略就自己分析吧，像時效、分類、狀態(tài)等，根據(jù)業(yè)務(wù)排一排

第二次提交判定：

1.每次提交生成一個request_id 每次請求都不同