分布式服務介面的冪等性如何設計（比如不能重複扣款）？
從這個問題開始，面試官就已經進入了實際的生產問題的面試了。
乙個分布式系統中的某個介面，該如何保證冪等性？這個事兒其實是你做分布式系統的時候必須要考慮的乙個生產環境的技術問題。啥意思呢？
你看，假如你有個服務提供一些介面供外部呼叫，這個服務部署在了 5 臺機器上，接著有個介面就是付款介面。然後人家使用者在前端上操作的時候，不知道為啥，總之就是乙個訂單不小心發起了兩次支付請求，然後這倆請求分散在了這個服務部署的不同的機器上，好了，結果乙個訂單扣款扣兩次。
或者是訂單系統呼叫支付系統進行支付，結果不小心因為網路超時了，然後訂單系統走了前面我們看到的那個重試機制，咔嚓給你重試了一把，好，支付系統收到乙個支付請求兩次，而且因為負載均衡演算法落在了不同的機器上，尷尬了。。。
所以你肯定得知道這事兒，否則你做出來的分布式系統恐怕容易埋坑。
這個不是技術問題，這個沒有通用的乙個方法，這個應該結合業務來保證冪等性。
所謂冪等性，就是說乙個介面，多次發起同乙個請求，你這個介面得保證結果是準確的，比如不能多扣款、不能多插入一條資料、不能將統計值多加了 1。這就是冪等性。
其實保證冪等性主要是三點：
實際運作過程中，你要結合自己的業務來，比如說利用 redis，用 orderid 作為唯一鍵。只有成功插入這個支付流水，才可以執行實際的支付扣款。
要求是支付乙個訂單，必須插入一條支付流水，order_id 建乙個唯一鍵unique key。你在支付乙個訂單之前，先插入一條支付流水，order_id 就已經進去了。你就可以寫乙個標識到 redis 裡面去，set order_id payed，下一次重複請求過來了，先查 redis 的 order_id 對應的 value，如果是payed就說明已經支付過了，你就別重複支付了。
參考：
分布式介面的冪等設計
什麼是介面的冪等性，介面的冪等性實際上就是介面可重複呼叫，在呼叫方多次呼叫的情況下，介面最終得到的結果是一致的。有些介面可以天然的實現冪等性，比如查詢介面，對於查詢來說，你查詢一次和兩次，對於系統來說，沒有任何影響，查出的結果也是一樣。除了查詢功能具有天然的冪等性之外，增加 更新 刪除都要保證冪等性...
分布式系統的介面冪等性設計
在微服務架構下，我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面，第一次呼叫超時了，然後呼叫方重試了一次 在訂單建立時，我們需要去扣減庫存，這時介面發生了超時，呼叫方重試了一次 當這筆訂單開始支付，在支付請求發出之後，在服務端發生了扣錢操作，介面響應超時了，呼叫方重試了一次 乙個訂單狀態...
dubbo 分布式系統中介面的冪等性該如何設計
一 問題 分布式系統中，分布式服務介面的冪等性如何設計 比如，不能重複扣款 從這個問題開始，面試官就已經進入了實際的生產問題的面試啦。分布式系統中的某個介面，要保證冪等性，如何保證？假如你有個服務提供1個介面，結果這個服務部署在5臺機器上。接著有個介面，就是付款介面，然後使用者在前端操作的時候，不知...