1. 程式人生 > >業務冪等性方案設計

業務冪等性方案設計

冪等概念:
冪等(idempotent、idempotence)是一個數學與計算機學概念,常見於抽象代數中。
在程式設計中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式,或冪等方法,是指可以使用相同引數重複執行,並能獲得相同結果的函式。這些函式不會影響系統狀態,也不用擔心重複執行會對系統造成改變。

例如,setTrue()函式就是一個冪等函式,無論多次執行,其結果都是一樣的.
      更復雜的操作冪等保證是利用唯一交易號(流水號)實現.

現實場景:
1、前端重複提交選中的資料給後臺伺服器,則後臺只產生唯一的結果;
2、我們發起一筆付款請求,伺服器只能扣使用者賬戶一次錢,即使遇到網路斷開後重發或系統其他的原因重發,也必須只能扣一次錢;
3、我們支付一次款項只能產生一條流水資料,如果產生多條流水則會出現問題;
等等以上場景的邏輯都需要冪等的特性來支援

實際上,我們常用的HTTP協議的方法是具有冪等性語義要求的,
比如:GET方法用於獲取資源,不應有副作用,因此是冪等的;
           POST方法用於建立資源,每次請求都會產生新的資源,因此不具備冪等性;
           PUT方法用於更新資源,是冪等的;
           DELETE方法用於刪除資源,也是冪等的。


常見用來保證冪等的技術方案:

  • 樂觀鎖機制

合理的使用樂觀鎖,通過version或者updateTime(timestamp)等其他條件,來做樂觀鎖的判斷條件。
例如
select * from tablename where condition=#condition# //取出要跟新的物件,帶有版本versoin
update tableName set name=#name#,version=version+1 where version=#version#

 

  • 悲觀鎖機制

每次操作資料時都會被加鎖(讀鎖、寫鎖、行鎖等),當其他執行緒想要訪問資料時,都需要阻塞掛起;現實中考慮的併發的要求,可能很少使用該方案;

  • 唯一索引機制

  在核心的流水錶中,使用流水號作為唯一索引,在前端支付或其他POST請求時,利用該唯一索引來防止產生重複資料;

  • SELECT + INSERT 機制

  也就是在插入前先查詢下是否已經存在,判斷是否已經執行過;這種機制適用於併發不高的後臺管理系統;

  • token機制 防止頁面重複提交

   實際需求:前端頁面維護資料只能被提交一次,但往往會由於卡頓導致重複點選或者網路重發或者NGINX重發等情況會導致重複請求
   解決辦法:
   如果是單個伺服器可以採用TOKEN加REDIS或TOKEN加其它框架來利用JVM記憶體,如果是叢集環境可以採用TOKEN加REDIS機制;