幂等性
原文地址：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一下
- 下一篇： 付费代理使用