寫在前面：之前在設計介面時因經驗尚淺，並未過多考慮冪等性，但這兩天出現的乙個線上問題讓我認識到了某些情況下介面冪等性的重要性；
非冪等場景：
服務a將單據a資訊通過rpc遠端過程呼叫傳給下游服務b介面（非冪等介面）用於生成關聯單據b，服務b介面會校驗是否已經接收過單據a，如果已接收過，會報錯『重複的單據』，如果未接收過，則生產關聯單據b並寫庫，將結果返回服務a，服務a收到結果後修改此單據狀態，將結果返回客戶端。簡化流程圖如下所示：
非冪等出現的問題：
服務a呼叫服務b後，服務b生成關聯單據b寫庫成功，返回成功給服務a；但由於網路抖動，服務a未接收到服務b返回的響應，預設認定失敗，返回客戶端失敗；業務人員重試，但由於服務b已接受過此單據a，會丟擲異常『重複單據a』，對於此單據a就永遠無法接受到單據b的成功響應，永遠為『處理失敗』狀態，與實際狀態不一致；（出現此問題後，首先確認單據a的關聯單據b已生成，然後手動修復服務a裡單據a的狀態為『處理成功』）
冪等性解決：
為了解決以上問題，就需要保證下游服務b介面對單據a維度做冪等性；判斷再次接受到單據a之後，不做任何操作，直接返回成功即可，服務a接受到成功後即可修改單據a狀態為『處理成功』；
介面的冪等性實際上就是介面可重複呼叫，在呼叫方多次呼叫的情況下，介面最終得到的結果是一致的。有些介面可以天然的實現冪等性，比如查詢介面，對於查詢來說，你查詢一次和兩次，對於系統來說，沒有任何影響。但對於有寫庫操作的增刪改介面，多次呼叫就會對系統有多次影響；
實現冪等性的關鍵在於識別重複的請求，對重複的請求返回成功即可，無需再對系統造成影響；
實現冪等性後的簡化流程圖：
寫在最後：冪等性應用的場景還有很多，實現也有很多方式，更有很多需要考慮的問題，隨著工作學習的深入，理解也一定會越來越深入的，加油！
部落格搬家：
保理業務術語
應收賬款 應收賬款 accounts receivable 指權利人因提供商品 服務 設施或出租資產而形成的債權，包括現有和將有的金錢債權及其產生的收益，但不包括因票據或其他有價 而產生的付款請求權。債權人 債務人 轉讓 反轉讓 反轉讓 reassignment 又稱回購 逆向轉讓。指受讓應收賬款的...
保理系統業務
保理又稱保付 托收保付，是 中以托收 賒銷方式結算貸款時，出口方為了規避收款風險而採用的一種請求第三者 保理商 承擔風險的做法。保理業務是一項集 融資 商業資信調查 應收賬款管理及信用風險承擔於一體的綜合性金融服務。與傳統結算方式相比，保理的優勢主要在於融資功能。保理商為其提供下列服務中的至少兩項 ...
轉賬業務場景
a轉給b100元 兩個關鍵點 1 a b sql在乙個事務中 2 a轉賬前，先查餘額 開啟事務 lined update set a.money a.money 100 where a.money 100 if lined 0 return 沒錢 update set b.money b.money...