資訊專欄INFORMATION COLUMN
摘要：冪等實(shí)現(xiàn)方案冪等性不能脫離業(yè)務(wù)來(lái)討論。在不同的需求場(chǎng)景下，實(shí)現(xiàn)冪等的思路和方案也會(huì)不同，一般有如下通用方案多版本并發(fā)控制這是樂(lè)觀鎖的一種實(shí)現(xiàn)，用于在數(shù)據(jù)庫(kù)并發(fā)訪問(wèn)時(shí)的情況。去重表這是利用數(shù)據(jù)庫(kù)表單的特性來(lái)實(shí)現(xiàn)冪等。
背景
在軟件系統(tǒng)的開(kāi)發(fā)過(guò)程中，我們可能有如下需求：
創(chuàng)建業(yè)務(wù)訂單，一次業(yè)務(wù)請(qǐng)求只能創(chuàng)建一個(gè)；
單個(gè)訂單請(qǐng)求調(diào)用支付接口，當(dāng)遇到網(wǎng)絡(luò)或系統(tǒng)故障請(qǐng)求重發(fā)，也應(yīng)該只支付一次；
單個(gè)訂單完成時(shí)，給用戶發(fā)送消息應(yīng)該只發(fā)一次；
等等很多情況下，都需要冪等的特性來(lái)支持。
冪等的概念冪等（idempotence）一詞原為數(shù)學(xué)上的概念，用一個(gè)最直觀的數(shù)學(xué)式子表達(dá)為：
f(f(x)) = f(x)
對(duì)應(yīng)到軟件開(kāi)發(fā)領(lǐng)域，即為同樣的請(qǐng)求被執(zhí)行一次與連續(xù)執(zhí)行多次的效果是一樣的，服務(wù)器的狀態(tài)也是一樣的，實(shí)際上就是接口的可重復(fù)調(diào)用（包括時(shí)間和空間上兩個(gè)維度）。
不是要求返回值完全相同，而且是指后續(xù)多余的調(diào)用對(duì)系統(tǒng)的數(shù)據(jù)一致性不造成破壞。對(duì)于寫入類操作，如果第一次寫入是成功的，后續(xù)的寫入應(yīng)該拋出異常或者空操作，或者執(zhí)行了寫入但是未對(duì)數(shù)據(jù)造成變化。對(duì)于讀取類操作，需要保證其實(shí)現(xiàn)上是真正的讀取，不能在讀操作中夾帶寫操作。
冪等性不能脫離業(yè)務(wù)來(lái)討論。
在不同的需求場(chǎng)景下，實(shí)現(xiàn)冪等的思路和方案也會(huì)不同，一般有如下通用方案：
這是樂(lè)觀鎖的一種實(shí)現(xiàn)，用于在數(shù)據(jù)庫(kù)并發(fā)訪問(wèn)時(shí)的情況。當(dāng)數(shù)據(jù)更新時(shí)需要去判斷版本號(hào)是否一致，如果不一致，則無(wú)法對(duì)數(shù)據(jù)進(jìn)行更新。例如請(qǐng)求支付接口進(jìn)行扣款時(shí)：
update table_name set deposit = deposit-#{payment}, version = version + 1 where orderId = #{orderId} and version = #{version}
這里orderId可進(jìn)一步設(shè)為主鍵或唯一索引，因?yàn)檫@樣是行鎖，否則更新操作時(shí)會(huì)鎖表。樂(lè)觀鎖在對(duì)已有數(shù)據(jù)進(jìn)行更新時(shí)既能保證效率，又能保證冪等。
2. 去重表這是利用數(shù)據(jù)庫(kù)表單的特性來(lái)實(shí)現(xiàn)冪等。以訂單請(qǐng)求支付場(chǎng)景為例：
將訂單號(hào)orderId設(shè)為去重表的唯一索引，每次請(qǐng)求支付都根據(jù)訂單號(hào)向去重表中插入一條數(shù)據(jù)，只有插入成功才繼續(xù)執(zhí)行支付操作，相當(dāng)于在事務(wù)的開(kāi)始階段加鎖。
考慮兩種失敗的情況：
Insert去重表失敗，事務(wù)回滾，無(wú)任何影響；
Insert去重表成功，支付業(yè)務(wù)操作失敗，事務(wù)回滾，刪除之前插入去重表的記錄，無(wú)任何影響；
以上兩種失敗的情況下，事務(wù)的冪等性是可以保持的，避免了單個(gè)訂單同時(shí)多次進(jìn)行支付的情況。
下圖為該支付場(chǎng)景下的時(shí)序圖：
與去重表思路相同，只是將對(duì)數(shù)據(jù)庫(kù)的的訪問(wèn)轉(zhuǎn)移到了對(duì)緩存（如redis）的訪問(wèn)，提高了效率。具體操作如下：
訂單發(fā)起支付請(qǐng)求，支付系統(tǒng)會(huì)去redis緩存中查詢是否存在該訂單號(hào)orderId的key，如果不存在，則向redis增加key為訂單號(hào)，然后開(kāi)始實(shí)際支付操作；如果查詢到存在該訂單號(hào)的key，則不進(jìn)行實(shí)際支付操作。無(wú)論支付操作成功或失敗，在支付操作結(jié)果返回后，在緩存中刪除該訂單號(hào)key。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/76621.html
摘要：解決冪等問(wèn)題的三部曲，也是作者的思考框架。這是解決冪等問(wèn)題的第二部曲列出并減少副作用的分析維度。所以在并發(fā)執(zhí)行的維度，將并發(fā)重復(fù)執(zhí)行變成串行重復(fù)執(zhí)行是最好的冪等解決方案。 綱要 文章目的：本文旨在提煉一套分布式冪等問(wèn)題的思考框架，而非解決某個(gè)具體的分布式冪等問(wèn)題。在這個(gè)框架體系內(nèi)，會(huì)有一些方案舉例說(shuō)明。文章目標(biāo)：希望讀者能通過(guò)這套思考框架設(shè)計(jì)出符合自己業(yè)務(wù)的完備的冪等解決方案。文章內(nèi)容...
摘要：總結(jié)的時(shí)間復(fù)雜度是，是空間是使用輔助棧來(lái)存儲(chǔ)最小值。項(xiàng)目就是為了解決配置繁瑣的問(wèn)題，最大化的實(shí)現(xiàn)約定大于配置。 前言 只有光頭才能變強(qiáng) Redis目前還在看，今天來(lái)分享一下我在秋招看過(guò)(遇到)的一些面試題(相對(duì)比較常見(jiàn)的) 0、final關(guān)鍵字 簡(jiǎn)要說(shuō)一下final關(guān)鍵字，final可以用來(lái)修飾什么？ 這題我是在真實(shí)的面試中遇到的，當(dāng)時(shí)答得不太好，現(xiàn)在來(lái)整理一下吧。 final可以修飾...
摘要：函數(shù)式編程者并沒(méi)有消除所有的副作用。我的結(jié)論是這里的并不違反減少或避免副作用的精神。一些語(yǔ)言允許你指定生成隨機(jī)數(shù)的種子。因此，我們必須將內(nèi)建的隨機(jī)數(shù)生成視為不純的一方。其他的錯(cuò)誤在程序運(yùn)行期間副作用可能導(dǎo)致的錯(cuò)誤是多種多樣的。 原文地址：Functional-Light-JS 原文作者：Kyle Simpson－《You-Dont-Know-JS》作者 關(guān)于譯者：這是一個(gè)流淌...
閱讀 3318·2019-08-29 16:17
閱讀 1975·2019-08-29 15:31
閱讀 2645·2019-08-29 14:09
閱讀 2548·2019-08-26 13:52
閱讀 744·2019-08-26 12:21
閱讀 2125·2019-08-26 12:08
閱讀 991·2019-08-23 17:08
閱讀 1922·2019-08-23 16:59
