任意多次執行所產生的影響均與一次執行的影響相同。
類似資料庫的update、set。
1、資料庫建立唯一性索引，可以保證最終插入資料庫的只有一條資料
2、token機制，每次介面請求前先獲取乙個token，然後再下次請求的時候在請求的header體中加上這個token，後台進行驗證，如果驗證通過刪除token，下次請求再次判斷token
3、悲觀鎖或者樂觀鎖，悲觀鎖可以保證每次for update的時候其他sql無法update資料(在資料庫引擎是innodb的時候,select的條件必須是唯一索引,防止鎖全表)
4、先查詢後判斷，首先通過查詢資料庫是否存在資料，如果存在證明已經請求過了，直接拒絕該請求，如果沒有存在，就證明是第一次進來，直接放行。
5、分布式鎖；實際常用此方式處理
6、狀態機 ；zk等
分布式 冪等性
現在你的服務提供一些外部介面呼叫，然後你這個服務又是部署在多台機器上的，然後前端在操作的時候正好呼叫了請求，假如我們的業務功能是扣款，然後在負載均衡的時候你的請求被傳送到不同的機器上，所以你需要保證的就是同樣的一次請求只能成功一次，另外的需要丟棄調。那麼如何保證分布式環境下的冪等性呢？保證冪等性主要...
分布式環境下保證冪等性
分布式環境中 非分布式也一樣 在對某個進行資料新增的時候比如 點讚，使用者點讚的時候將點贊資訊存入到點讚表中，然後就是校驗點讚查詢是否存在一條記錄，考慮到一些外界原因 dubbo 重新發起請求，當然正式環境下是關閉重新請求的，插入成功後沒有給客戶端返回成功資訊等等。導致重複提交點讚資訊，這個時候資料...
分布式系統的介面冪等性設計
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...