1. 程式人生 > >介面冪等性如何實現?

介面冪等性如何實現?

導讀

  • 轉載自冪等性如何實現?深入瞭解一波!!!
  • 現在這個時代大家可能最關心的就是錢了,那麼有沒有想過你銀行轉賬給你沒有一次是轉多的,要麼失敗,要麼成功,為什麼不能失誤一下多轉一筆呢?醒醒吧年輕人,別做夢了,做銀行的能那麼傻x嗎?
  • 今天我們就來談一談為什麼銀行轉賬不能多給我轉一筆?關乎到錢的問題,小夥伴們打起精神!!!
  • 要想要理解上述的疑惑,不得不提的一個概念就是冪等性,至於什麼是冪等性,如何通過程式碼實現冪等性,下面將會詳細講述。

什麼是冪等性

  • 所謂冪等性通俗的將就是一次請求和多次請求同一個資源產生相同的副作用。用數學語言表達就是f(x)=f(f(x))
  • 維基百科的冪等性定義如下:
冪等(idempotent、idempotence)是一個數學與計算機學概念,常見於抽象代數中。
在程式設計中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式,或冪等方法,是指可以使用相同引數重複執行,並能獲得相同結果的函式。這些函式不會影響系統狀態,也不用擔心重複執行會對系統造成改變。例如,“setTrue()”函式就是一個冪等函式,無論多次執行,其結果都是一樣的,更復雜的操作冪等保證是利用唯一交易號(流水號)實現.

為什麼需要冪等性

  • 在系統高併發的環境下,很有可能因為網路,阻塞等等問題導致客戶端或者呼叫方並不能及時的收到服務端的反饋甚至是呼叫超時的問題。總之,就是請求方呼叫了你的服務,但是沒有收到任何的資訊,完全懵逼的狀態。比如訂單的問題,可能會遇到如下的幾個問題:
  1. 建立訂單時,第一次呼叫服務超時,再次呼叫是否產生兩筆訂單?
  2. 訂單建立成功去減庫存時,第一次減庫存超時,是否會多扣一次?
  3. 訂單支付時,服務端扣錢成功,但是介面反饋超時,此時再次呼叫支付,是否會多扣一筆呢?
  • 作為消費者,前兩種能接受,第三種情況就MMP了,哈哈哈!!!這種情況一般有如下兩種解決方式
  1. 服務方提供一個查詢操作是否成功的api,第一次超時之後,呼叫方呼叫查詢介面,如果查到了就走成功的流程,失敗了就走失敗的流程。
  2. 另一種就是服務方需要使用冪等的方式保證一次和多次的請求結果一致。

HTTP的冪等性

  • GET:只是獲取資源,對資源本身沒有任何副作用,天然的冪等性。
  • HEAD:本質上和GET一樣,獲取頭資訊,主要是探活的作用,具有冪等性。
  • OPTIONS:獲取當前URL所支援的方法,因此也是具有冪等性的。
  • DELETE:用於刪除資源,有副作用,但是它應該滿足冪等性,比如根據id刪除某一個資源,呼叫方可以呼叫N次而不用擔心引起的錯誤(根據業務需求而變)。
  • PUT:用於更新資源,有副作用,但是它應該滿足冪等性,比如根據id更新資料,呼叫多次和N次的作用是相同的(根據業務需求而變)。
  • POST:用於新增資源,多次提交很可能產生副作用,比如訂單提交,多次提交很可能產生多筆訂單。

冪等性的實現方式

  • 對於客戶端互動的介面,可以在前端攔截一部分,例如防止表單重複提交,按鈕置灰,隱藏,不可點選等方式。但是前端進行攔截器顯然是針對普通使用者,懂點技術的都可以模擬請求呼叫介面,所以後端冪等性很重要。
  • 後端的冪等性如何實現?將會從以下幾個方面介紹。

資料庫去重表

  • 在往資料庫中插入資料的時候,利用資料庫唯一索引特性,保證資料唯一。比如訂單的流水號,也可以是多個欄位的組合。
  • 實現比較簡單,讀者可以自己實現看看,這裡不再提供demo了。

狀態機

  • 很多業務中多有多個狀態,比如訂單的狀態有提交、待支付、已支付、取消、退款等等狀態。後端可以根據不同的狀態去保證冪等性,比如在退款的時候,一定要保證這筆訂單是已支付的狀態。
  • 業務中常常出現,讀者可以自己實現看看,不再提供demo。

TOKEN機制

  • 針對客戶端連續點選或者呼叫方的超時重試等情況,例如提交訂單,此種操作就可以用Token的機制實現防止重複提交。
  • TOKEN機制如何實現?簡單的說就是呼叫方在呼叫介面的時候先向後端請求一個全域性ID(TOKEN),請求的時候攜帶這個全域性ID一起請求,後端需要對這個全域性ID校驗來保證冪等操作,流程如下圖:

  • 主要的流程步驟如下:
    • 客戶端先發送獲取token的請求,服務端會生成一個全域性唯一的ID儲存在redis中,同時把這個ID返回給客戶端。
    • 客戶端呼叫業務請求的時候必須攜帶這個token,一般放在請求頭上。
    • 服務端會校驗這個Token,如果校驗成功,則執行業務。
    • 如果校驗失敗,則表示重複操作,直接返回指定的結果給客戶端。
  • 通過以上的流程分析,唯一的重點就是這個全域性唯一ID如何生成,在分散式服務中往往都會有一個生成全域性ID的服務來保證ID的唯一性,但是工程量和實現難度比較大,UUID的資料量相對有些大,此處陳某選擇的是雪花演算法生成全域性唯一ID,不瞭解雪花演算法的讀者下一篇文章會著重介紹。

程式碼實現

  • 陳某選擇的環境是SpringBoot+Redis單機環境+註解+攔截器的方式實現,只是演示一下思想,具體的程式碼可以參照實現。
  • redis如何實現,獲取Token介面將全域性唯一Id存入Redis(一定要設定失效時間,根據業務需求),業務請求的時候直接從redis中刪除,根據delete的返回值判斷,返回true表示第一次請求,返回false表示重複請求。程式碼如下:
@Service
public class TokenServiceImpl implements TokenService {
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public String getToken() {
        //獲取全域性唯一id
        long nextId = SnowflakeUtil.nextId();
        //存入redis,設定10分鐘失效
        stringRedisTemplate.opsForValue().set(String.valueOf(nextId), UUID.randomUUID().toString(),10, TimeUnit.MINUTES);
        return String.valueOf(nextId);
    }

    /**
    * 刪除記錄,true表示第一次提交,false重複提交
    */
    @Override
    public Boolean checkToken(String token) {
        return stringRedisTemplate.delete(token);
    }
}
  • 註解的實現如下,標註在controller類上表示當前類上全部介面都做冪等,標註單個方法上,表示單個介面做冪等操作。
/**
 * @Description 冪等操作的註解
 * @Author CJB
 * @Date 2020/3/25 10:19
 */
@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RepeatLimiter {
}
  • 請求頭的攔截器,用於提取請求頭和校驗請求頭,如下:
/**
 * @Description 獲取請求頭的資訊,具體校驗邏輯讀者自己實現
 * @Author CJB
 * @Date 2020/3/25 11:09
 */
@Component
public class HeaderIntercept implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //獲取token
        String token = request.getHeader(HeaderConstant.TOKEN);
        //校驗邏輯
        if (!validToken(token))
            throw new TokenInvalidException("TOKEN失效");
        //獲取其他的引數.....
        RequestHeader header = RequestHeader.builder()
                .token(token)
                .build();
        //放入request中
        request.setAttribute(HeaderConstant.HEADER_INFO,header);
        return true;
    }

    /**
     * 校驗token,邏輯自己實現
     * @param token
     * @return
     */
    private boolean validToken(String token){
        return Boolean.TRUE;
    }
}
  • 保證冪等性的攔截器,直接從redis中刪除token,成功則第一次提交,不成功則重複提交。
@Component
public class RepeatIntercept implements HandlerInterceptor {

    @Autowired
    private TokenService tokenService;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (handler instanceof HandlerMethod){
            //獲取方法上的引數
            RepeatLimiter repeatLimiter = AnnotationUtils.findAnnotation(((HandlerMethod) handler).getMethod(), RepeatLimiter.class);

            if (Objects.isNull(repeatLimiter)){
                //獲取controller類上註解
                repeatLimiter=AnnotationUtils.findAnnotation(((HandlerMethod) handler).getBean().getClass(),RepeatLimiter.class);
            }

            //使用註解,需要攔截驗證
            if (Objects.nonNull(repeatLimiter)){
                //獲取全域性token,表單提交的唯一id
                RequestHeader info = RequestContextUtils.getHeaderInfo();

                //沒有攜帶token,拋異常,這裡的異常需要全域性捕獲
                if (StringUtils.isEmpty(info.getToken()))
                    throw new RepeatException();

                //校驗token
                Boolean flag = tokenService.checkToken(info.getToken());

                //刪除失敗,表示
                if (Boolean.FALSE.equals(flag))
                    //丟擲重複提交的異常
                    throw new RepeatException();
            }
        }
        return true;
    }
}
  • 介面冪等實現,程式碼如下:
@RestController
@RequestMapping("/order")
public class OrderController {

    @Autowired
    private OrderService orderService;

    /**
     * 下單
     * @param order
     * @return
     */
    @PostMapping
    @RepeatLimiter  //冪等性保證
    public CommenResult add(@RequestBody Order order){
        orderService.save(order);
        return new CommenResult("200","下單成功");
    }
}

演示

  • 傳送getToken的請求獲取Token

  • 攜帶Token下單第一次:

  • 第二次下單:

相關推薦

介面如何實現

導讀 轉載自冪等性如何實現?深入瞭解一波!!! 現在這個時代大家可能最關心的就是錢了,那麼有沒有想過你銀行轉賬給你沒有一次是轉多的,要麼失敗,要麼成功,為什麼不能失誤一下多轉一筆呢?醒醒吧年輕人,別做夢了,做銀行的能那麼傻x嗎? 今天我們就來談一談為什麼銀行轉賬不能多給我轉一筆?關乎到錢的問題,小夥伴們打起

實現介面的幾種方案

搶微信紅包的時候我們都知道:一個紅包一旦你搶過之後,以後無論你點多少次都是一樣的結果。紅包會提示你已經搶過此紅包,而不會讓你再搶一次。 搶紅包介面就是一個非常典型的冪等介面,搶一次和搶多次具有一樣的效果。類似的介面在我們的開發過程中會有很多,比如在電商的下單過程中: > 訂單建立介面,第一次呼叫返回超時了

網際網路 API 介面設計

WEB 資源或 API 方法的冪等性是指一次和多次請求某一個資源應該具有同樣的副作用。冪等性是系統的介面對外一種承諾(而不是實現), 承諾只要呼叫介面成功, 外部多次呼叫對系統的影響是一致的。冪等性是分散式系統設計中的一個重要概念,對超時處理、系統恢復等具有重要意義。宣告為冪

如何處理介面問題

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

介面的解決方案

在程式設計中,冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式指的是那些使用相同引數重複執行也能獲得相同結果的函式。這些函式不會影響系統狀態,也不用擔心重複執行會對系統造成改變。比如說getIdCard()函式和setTrue()函式就是冪等函式。 冪等在我的理解裡就是,一個操作不

架構設計 | 介面原則,防重複提交Token管理

本文原始碼:[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、冪等性概念 ## 1、冪等

ASP.NET WebApi服務介面如何防止重複請求實現HTTP(八)

一、背景描述與課程介紹 明人不說暗話,跟著阿笨一起玩WebApi。在我們平時開發專案中可能會出現下面這些情況; 1)、由於使用者誤操作,多次點選網頁表單提交按鈕。由於網速等原因造成頁面卡頓,使用者重複重新整理提交頁面。黑客或惡意使用者使用postman等工具重複惡意提交表單(攻擊網站)。這些情況都會導

介面方案

冪等性介面方案 什麼是介面的冪等性 介面可重複呼叫,在呼叫方多次呼叫的情況下,介面最終得到的結果是一致的。有些介面可以天然的實現冪等性,比如查詢介面,對於查詢來說,你查詢一次和兩次,對於系統來說,沒有任何影響,查出的結果也是一樣。 問題舉例: 在微服務架構下,我們在完成一個訂單

後端介面

介面的冪等性:就是介面可重複呼叫,在呼叫多次的情況下,介面最終得到的結果是一致的。 所有的介面可分為增刪改查。,查詢功能具有天然的冪等性,增加、更新、刪除都要保證冪等性。 全域性唯一ID 全域性唯一ID就是根據業務的操作和內容生成一個全域性ID,在執行操作前先根

Java學習資料支付介面設計

1. 什麼是冪等性? 在數學中的冪等性定義: 在某二元運算下,冪等元素是指被自己重複運算(或對於函式是為複合)的結果等於它自己的元素。例如,乘法下唯一兩個冪等實數為0和1。 即 s * s = s 某一元運算為冪等時,其作用在任一元素兩次後會和其作用一次的結果相同。例如,高斯符號便是冪等的,即f(f(x

動力節點Java學習資料支付介面設計

1. 什麼是冪等性? 在數學中的冪等性定義: 在某二元運算下,冪等元素是指被自己重複運算(或對於函式是為複合)的結果等於它自己的元素。例如,乘法下唯一兩個冪等實數為0和1。 即 s * s = s 某一元運算為冪等時,其作用在任一元素兩次後會和其作用一次的結果相同。例如,高斯符號便是

如何保證微服務介面

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

通過實際業務場景理解後端介面

寫在前面:之前在設計介面時因經驗尚淺,並未過多考慮冪等性,但這兩天出現的一個線上問題讓我認識到了某些情況下介面冪等性的重要性; 非冪等場景: 服務A將單據A資訊通過RPC遠端過程呼叫傳給下游服務B介

34、分散式服務介面如何設計(比如不能重複扣款)?

1、面試題 分散式服務介面的冪等性如何設計(比如不能重複扣款)? 2、面試官心裡分析 從這個問題開始,面試官就已經進入了實際的生產問題的面試了。 一個分散式系統中的某個介面,要保證冪等性,該如何保證?這個事兒其實是你做分散式系統的時候必須要考慮的一個生產環境的技術問題。啥意思呢?

MQ如何實現

一、緣起 如《訊息匯流排訊息必達》所述,MQ訊息必達,架構上有兩個核心設計點: (1)訊息落地 (2)訊息超時、重傳、確認 再次回顧訊息匯流排核心架構,它由傳送端、服務端、固化儲存、接收端四大部分組成。 為保證訊息的可達性,超時、重傳、確認機制可能導致訊

實現的方案

實際系統中有很多操作,是不管做多少次,都應該產生一樣的效果或返回一樣的結果。 例如: 1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。 2. 我們發起一筆付款請求,應該只扣使用者賬戶一次錢,當遇到網路重發或系統bug重發,也應該只扣一次錢;

探討一下實現的幾種方式

什麼是冪等性? 對於同一筆業務操作,不管呼叫多少次,得到的結果都是一樣的。 冪等性設計 我們以對接支付寶充值為例,來分析支付

Redis如何保證介面

在最近的一次業務升級中,遇到這樣一個問題,我們設計了新的賬戶體系,需要在使用者將應用升級之後將原來賬戶的資料手動的同步過來,就是需

Kafka原理及實現剖析

1.概述 最近和一些同學交流的時候反饋說,在面試Kafka時,被問到Kafka元件組成部分、API使用、Consumer和Producer原理及作用等問題都能詳細作答。但是,問到一個平時不注意的問題,就是Kafka的冪等性,被卡主了。那麼,今天筆者就為大家來剖析一下Kafka的冪等性原理及實現。 2.內容

什麽是分布式系統中的

數據操作 返回 另一個 tid 訂單 增加 簡單的 事務 既然 最近很多人都在談論冪等性,好吧,這回我也來聊聊這個話題,光看著倆字,一開始的確有點一頭霧水,語文不好嘛,詞太專業嘛,對吧 現如今我們的系統大多拆分為分布式SOA,或者微服務,一套系統中包含了多個子系統服務,