概念：其任意屢次執行所產生的影響均與一次執行的影響相同。重複的場景包括：前端
前端重複提交：提交訂單，用戶快速重複點擊屢次，形成後端生成多個內容重複的訂單。
接口超時重試：對於給第三方調用的接口，爲了防止網絡抖動或其餘緣由形成請求丟失，這樣的接口通常都會設計成超時重試屢次。
消息重複消費：MQ消息中間件，消息重複消費
實現方式
一、Token機制
服務端提供了發送token的接口。咱們在分析業務的時候，哪些業務是存在冪等問題的，就必須在執行業務前，先去獲取token，服務器會把token保存到redis中。（微服務確定是分佈式了，若是單機就適用jvm緩存）。redis
而後調用業務接口請求時，把token攜帶過去，通常放在請求頭部。服務器判斷token是否存在redis中，存在表示第一次請求，能夠繼續執行業務，執行業務完成後，最後須要把redis中的token刪除。數據庫
若是判斷token不存在redis中，就表示是重複操做，直接返回重複標記給client，這樣就保證了業務代碼，不被重複執行。後端
二、數據庫去重表
往去重表裏插入數據的時候，利用數據庫的惟一索引特性，保證惟一的邏輯。惟一序列號能夠是一個字段，例如訂單的訂單號，也能夠是多字段的惟一性組合。緩存
三、Redis實現
Redis實現的方式就是將惟一序列號做爲Key，惟一序列號的生成方式和上面介紹的防重表的同樣，value能夠是你想填的任何信息。服務器
惟一序列號也能夠是一個字段，例如訂單的訂單號，也能夠是多字段的惟一性組合。固然這裏須要設置一個 key 的過時時間，不然 Redis 中會存在過多的 key。具體校驗流程以下圖所示，實現代碼也很簡單這裏就不寫了。微信
四、多版本控制
多版本併發控制，樂觀鎖的一種實現，在數據更新時須要去比較持有數據的版本號，版本號不一致的操做沒法成功。網絡
冪等性測試
（1）須要更多的關注業務性質和產品設計上，是否須要作到冪等，是時間維度的冪等仍是空間維度的冪等；併發
（2）接口的冪等測試必定不能遺漏，因爲冪等場景相對容易製造出來，冪等測試的難度遠遠小於併發測試，所以在作接口測試時不妨對每一個接口都思考一下是否須要冪等，須要的話就測試一下其冪等性；app
（3）業務場景，特別是涉及到資金流動的業務場景，對失敗重試機制必定要慎重；
（4）前端冪等測試，注意按鈕的屢次快速點擊；
（5）後端冪等測試，就是接口的冪等測試，使用postman或jmeter屢次發送同一參數的請求，查看服務端響應。
本文分享自微信公衆號 - 測試開發進階圈（testAdvance）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。