幂等性
原文地址:https://blog.csdn.net/tjgamejx2/article/details/51011425
1、導語
我認為我是個懶惰的人,很少去寫點什么東西,哪怕是看書,我也從來沒有看完過一本書。我買過不少書籍,但是幾乎每本書籍都沒有看完三分之一,一個是因為我懶惰,其次是一本書對于我來說有效信息量可能不足20%甚至更低,我需要去篩選一些我感興趣的或者說對我來說有用的片段,這使得我失去去翻它的興趣。我幾乎所有的能力都學習于互聯網,感謝那些樂于分享自己心得的同仁。終于下定決心,自己去寫一些什么東西回報一下,力求有效信息量超過60%,寫一些對讀者有用,讀者愿意看下去的東西。
羅里吧嗦了半天,開始進入正題吧,這是我將寫下的第一篇博客,冪等性。之所以開篇就寫冪等性,是因為我認為冪等性是架構設計中的基礎中的基礎。,沒法保證冪等性,咱們接下來沒法談數據一致性與事物完整性了。
2、什么是冪等性
抄用一段數學上的定義:f(f(x)) =?f(x)。x被函數f作用一次和作用無限次的結果是一樣的。冪等性應用在軟件系統中,我把它簡單定義為:某個函數或者某個接口使用相同參數調用一次或者無限次,其造成的后果是一樣的,在實際應用中一般針對于接口進行冪等性設計。舉個栗子,在系統中,調用方A調用系統B的接口進行用戶的扣費操作時,由于網絡不穩定,A重試了N次該請求,那么不管B是否接收到多少次請求,都應該保證只會扣除該用戶一次費用。
3、冪等性設計
冪等性一般應用于協議設計,TCP協議支持冪等嗎?答案是肯定的,在網絡不穩定時,操作系統可以肆無忌憚的重發TCP報文片段。TCP協議能夠保證冪等的核心在于sequence number字段,一個序列號的在較長的一段時間內均不會出現重復。對于應用層的協議設計,原理和TCP是類似的,我們需要一個不重復的序列號。再簡單一點說,在一個業務流程的處理中,我們需要一個不重復的業務流水號,以保證冪等性。
?
舉個實際應用場景:用戶A在網頁上發起一筆游戲充值請求,瀏覽器引導用戶去銀行支付,支付成功后系統給用戶進行充值。
?
協議設計上,我們通過全局唯一的充值訂單號貫穿整個業務流程,使該業務支持冪等。
?
應用實現上,我們列舉在銀行支付成功后回調系統,進行充值的步驟進行說明。
func pay_notify(orderid,value,state){//有問題的實現order = db.query("select * from payorder where orderid=$orderid");check(order,orderid,value,state);//判斷支付金額是否與訂單金額一致,判斷是否是支付成功回調。if(order.state=='未支付'){db.update("update payorder set state='已支付' where orderid=$orderid");charge(order.username,value);//執行充值}else{return result("訂單已處理")//返回訂單已處理,或者返回處理成功}上述實現的問題在于,當回調出現并發時,order.state已經是臟讀了,有可能重復充值,該實現并不能100%保證冪等。
列舉三種改進方式:
1、悲觀鎖,select for update,整個執行過程中鎖定該訂單對應的記錄。
2、樂觀鎖,affectrows = db.update("update payorder set state='已支付' where orderid=$orderid and state='未支付' "),如果affectrows=1,執行充值,否則返回已處理。
3、定義notifylog表,orderid為unique key或者primary key,執行前,先insert,若insert成功則執行充值,否則返回已處理。
以上簡單例子用以說明冪等性常用應用實現,在SOA化系統中,可能很多原子功能都被拆分到不同的進程里,如charge充值這個函數,可能在另一個進程中,那么整個業務的鏈路就會更長,可能回調成功了,但是充值失敗。同理,只要充值接口保證冪等性,對于已經回調過但是充值結果未返回的請求,回調接收程序,應當重復發起充值請求。更深入更復雜的應用場景,在數據一致性中再細講。
?
4、總結
業務層設計協議時,要求請求方定義不重復的業務流水號。應用實現時,利用數據庫樂觀鎖、插入unique key的日志等方式保證并發時的冪等。
冪等性把關環節,在協議設計評審中,評審重要業務RPC或者http接口是否支持冪等,代碼評審中,重點把關請求并發時,是否仍舊能夠保證冪等性。設計人員和具體實現人員在實現過程中,也應該時刻自審冪等性的實現是否過關。
總結
- 上一篇: 法务管理项目结项了mark一下
- 下一篇: 付费代理使用