冪等性學習及介面的冪等性

2022-03-26 23:34:21 字數 1989 閱讀 8519

冪等性學習

一:什麼是冪等性

在這裡需要有以下幾個問題需要注意:

2:冪等性不僅僅只是一次或者多次請求的時候對資源沒有***。比如根據id對資料庫的查詢操作,此操作對資料庫沒有增刪改,所以多次查詢操作對資料庫結果是沒有任何影響的;

3:冪等性還包括了第一次請求資源的時候,對資源產生了***,但是在以後多次同樣的請求操作的時候,都不會在對資源產生***了。比如我們根據id更新訂單狀態從支付中變為支付完成這個操作,在執行第一次的時候,會更新為支付完成。之後在根據這個id執行此操作,無論執行多少次其結果和第一次執行後的結果一樣;

5:需要說明的是網路超時、服務宕機等問題,不是冪等的範圍。

冪等性是系統服務對外的一種承諾(注意,是一種承諾,而不是一種實現),介面服務提供方承諾只要呼叫介面成功了,外部多次呼叫對系統的影響是一致的。這裡需要強調一點就是,宣告為冪等的服務會認為呼叫方呼叫失敗是常態,是正常業務,並且允許在呼叫失敗後必然會有重試的。

二:什麼情況下需要使用冪等

在我們開發中,經常會遇到乙個頭疼的事情—重複提交的情況。重複提交情況有多種原因產生的。如由於網路問題無法收到請求結果情況下而重新發起的請求或者是因為呼叫方前端操作抖動而造成的重複提交。

重複提交操作帶來的嚴重後果在交易系統、支付系統中因重複提交而產生的問題尤其的明顯。如:我們發起支付的時候向支付寶支付請求,無論是交易系統自身bug還是交易系統與支付寶之間的網路問題導致重**送,支付寶應該並且必須只能扣使用者一次錢的。在這種需求下的系統在設計的時候,我們就需要將系統或者服務設計成冪等的。

三:冪等和防重複提交比較

重複提交:重複提交是在第一次請求成功的情況下,人為的進行多次操作,從而導致不滿足冪等性要求的服務多次改變資料狀態。

冪等:更多使用的情況是第一次請求知道結果(比如常見的網路抖動導致連線超時)或者失敗異常情況下,發起多次請求的,其目的是多次確認第一次請求成功,卻不會因為多次請求而出現多次的狀態變化。

什麼情況下需要保障冪等性?

在這裡,我們以sql為例來講解。在下面三種場景中,只要第三種場景需要開發人員使用其他策略來保障冪等性:

1:查詢情況

select * from table where id = 2

無論執行多少次都不會對資源造成***,所以可以說是天然的冪等

2:根據id更新

update table set status =1 where id =2

無論執行成功多少次狀態都是一致的,第一次執行成功對資源造成的***和多次執行成功對資料造成的***是一樣的。因此可以說這種場景也是冪等操作

3:不是冪等情況

update table set version = version+1 where id = 2

每次執行的結果都會發生變化,也就是說對資源造成了***,這種不是冪等的。這種情況如果想要保證冪等,語句可以這麼寫:update table set version = version+1 where id = 2 and version = 1.這樣就可以保證冪等了。

為什麼要設計冪等性的服務?

冪等性的服務可以使得客戶端的處理業務邏輯變的簡單了,但是確實以犧牲服務端邏輯變複雜為代價的。因為在滿足冪等服務的需求下邏輯至少需要包含以下兩點:

2:在服務改變狀態的業務邏輯前,保證防重複提交的邏輯

冪等的不足:

通過上面我們知道了冪等服務是以犧牲服務提供者邏輯和成本為代價的。所以,是否有必要,需要根據具體場景具體來分析的。因此除了業務上的特殊要求外,盡量不要提供冪等的介面。

1:增加了額外的控制冪等的業務邏輯,複雜了業務功能;

2:把並行執行的功能改為序列執行,這樣就降低了執行的效率。

保證冪等策略

其實在保證冪等的業務會通過唯一的業務單號來保證的。也就是說相同的單號,被認為是同一筆業務。使用唯一的業務單號來確保,後面多次相同的業務單號的的處理邏輯和執行兄啊過是一致的。我們以常見的支付為例(在不考慮併發情況下),實現冪等很簡單:

1:先查詢一下訂單是否已經支付過

2:如果已經支付過,則返回支付成功;如果沒有支付,在進行支付流程操作後,將訂單狀態修改為已支付。

介面的冪等性

在微服務架構下,我們在完成乙個訂單流程時經常遇到下面的場景 乙個訂單建立介面,第一次呼叫超時了,然後呼叫方重試了一次 在訂單建立時,我們需要去扣減庫存,這時介面發生了超時,呼叫方重試了一次 當這筆訂單開始支付,在支付請求發出之後,在服務端發生了扣錢操作,介面響應超時了,呼叫方重試了一次 乙個訂單狀態...

介面的冪等性

乙個操作,無論執行多少次,產生的效果和返回的結果都是一樣的.查詢和刪除操作具有天然的冪等性,新增和修改需要保證冪等性.在redis中儲存token實現冪等性 當客戶端需要請求新增或修改介面時,需要先向伺服器請求token 伺服器接收到客戶端請求token的請求,生成token並儲存在redis中,然...

介面的冪等性

介面冪等性就是使用者對於同一操作發起的一次請求或者多次請求的結果是一致的,不會因為多次點選而產生了 舉個最簡單的例子,那就是支付,使用者購買商品後支付,支付扣款成功,但是返回結果的時候網路異常,此時錢已經扣了,使用者再次點選按鈕,此時會進行第二次扣款,返回結果成功,使用者查詢餘額返發現多扣錢了,流水...