乙個操作,無論執行多少次, 產生的效果和返回的結果都是一樣的.
查詢和刪除操作具有天然的冪等性, 新增和修改需要保證冪等性.
在redis中儲存token實現冪等性
當客戶端需要請求新增或修改介面時, 需要先向伺服器請求token;
伺服器接收到客戶端請求token的請求, 生成token並儲存在redis中, 然後將生成的token返回給客戶端;
客戶端接收到token, 帶著token請求新增或修改介面;
伺服器接收到新增或修改請求, 將請求攜帶的token從redis中刪除, 如果刪除成功, 繼續執行新增或刪除操作, 如果刪除失敗, 就說明是重複操作, 直接放棄;
之所以使用刪除token來判斷token存在, 而不是select and delete, 是因為select and delete存在併發問題;
唯一索引
使用唯一索引, 例如將支付記錄表中的訂單號字段新增唯一索引, 這樣重複新增的支付記錄就會直接失敗
悲觀鎖認為在查詢和修改的過程中資料一定會被修改, 所以在讀取後對資料加鎖, 修改完後解鎖
select
*from my_order where id=
1for
update
;//mysql實現的悲觀鎖
在查詢的記錄都有乙個version欄位, 只要version欄位沒被修改, 就認為資料在沒被修改過.
存在aba的問題
分布式鎖
介面的冪等性
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...
介面的冪等性
介面冪等性就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了 舉個最簡單的例子，那就是支付，使用者購買商品後支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，使用者再次點選按鈕，此時會進行第二次扣款，返回結果成功，使用者查詢餘額返發現多扣錢了，流水...
冪等性學習及介面的冪等性
冪等性學習 一 什麼是冪等性 在這裡需要有以下幾個問題需要注意 2 冪等性不僅僅只是一次或者多次請求的時候對資源沒有 比如根據id對資料庫的查詢操作，此操作對資料庫沒有增刪改，所以多次查詢操作對資料庫結果是沒有任何影響的 3 冪等性還包括了第一次請求資源的時候，對資源產生了 但是在以後多次同樣的請求...