在分布式架構(soa、微服務化)裡面，一套系統會由多個子系統進行組成，形成乙個產品。在進行服務的拆分後，會存在子系統之間的呼叫(利用rpc協議完成通訊)，系統之間的通訊會存在乙個問題(單體架構不存在)：業務在完成乙個方法的呼叫後，單體架構只會出現兩種情況-成功、失敗，但是在分布式架構裡面涉及到遠端通訊，會出現第三種狀態-未知狀態，主要體現在超時、網路延遲、資料報請求丟失等等，這會導致服務的呼叫端對當前結果的未知，如果在這種場景下，呼叫端再一次重試發起這個請求後，也許服務端對當前請求已經處理過了 ，服務端相當於收到了兩次當前請求，如果我們不對這種情況進行相應的處理，會導致資料庫進行多次的累加/累減/更新。
如支付場景：使用者發起兩次支付操作，操作的是同一訂單，如果不進行相應的處理，會導致使用者進行兩次扣款。
冥等性就是為了解決上述的一種業務場景所提出的方案，那什麼是服務的冥等性？
使用者對同一次操作發起多次請求後，對資料影響的結果是不變的(只影響一次)
使用者發起請求，在服務端收到該請求後，會對某乙個關鍵的資料設定乙個唯一約束，如後面多次請求過來後，是不能正常入庫的，就會丟擲乙個exception，服務端可以根據異常進行相應的處理或不處理。
什麼是狀態機，它是一種特殊的組織**。使用狀態機可以隨時確保物件所處的乙個狀態，以及在當前狀態下能做的事情。
簡單來說，對於一條資料，它本身存在乙個狀態，不同狀態所能進行操作不一樣。
狀態機怎麼實現冥等呢？
如使用者發起兩次支付操作，操作的是同一訂單，為訂單新增狀態，修改資料庫時，以當前狀態為條件進行修改
update tbl_order set *** = *** where
status=0
# 0表示未支付狀態
介面的冪等性怎麼設計？
一 什麼是冪等?看一下維基百科怎麼說的 冪等性 多次呼叫方法或者介面不會改變業務狀態，可以保證重複呼叫的結果和單次呼叫的結果一致。二 使用冪等的場景 1 前端重複提交 使用者註冊，使用者建立商品等操作，前端都會提交一些資料給後台服務，後台需要根據使用者提交的資料在資料庫中建立記錄。如果使用者不小心多...
介面的冪等性
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...
介面的冪等性
乙個操作,無論執行多少次,產生的效果和返回的結果都是一樣的.查詢和刪除操作具有天然的冪等性,新增和修改需要保證冪等性.在redis中儲存token實現冪等性 當客戶端需要請求新增或修改介面時,需要先向伺服器請求token 伺服器接收到客戶端請求token的請求,生成token並儲存在redis中,然...