介面冪等性如何實現?

  • 2020 年 3 月 26 日
  • 筆記

導讀

  • 轉載自冪等性如何實現?深入了解一波!!!
  • 現在這個時代大家可能最關心的就是錢了,那麼有沒有想過你銀行轉賬給你沒有一次是轉多的,要麼失敗,要麼成功,為什麼不能失誤一下多轉一筆呢?醒醒吧年輕人,別做夢了,做銀行的能那麼傻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下單第一次:

  • 第二次下單: