1. 程式人生 > >如何保證微服務介面的冪等性

如何保證微服務介面的冪等性

在微服務架構下,我們在完成一個訂單流程時經常遇到下面的場景:

一個訂單建立介面,第一次呼叫超時了,然後呼叫方重試了一次 
在訂單建立時,我們需要去扣減庫存,這時介面發生了超時,呼叫方重試了一次 
當這筆訂單開始支付,在支付請求發出之後,在服務端發生了扣錢操作,介面響應超時了,呼叫方重試了一次 
一個訂單狀態更新介面,呼叫方連續傳送了兩個訊息,一個是已建立,一個是已付款。但是你先接收到已付款,然後又接收到了已建立 
在支付完成訂單之後,需要傳送一條簡訊,當一臺機器接收到簡訊傳送的訊息之後,處理較慢。訊息中介軟體又把訊息投遞給另外一臺機器處理

以上問題,就是在單體架構轉成微服務架構之後,帶來的問題。當然不是說單體架構下沒有這些問題,在單體架構下同樣要避免重複請求。但是出現的問題要比這少得多。

為了解決以上問題,就需要保證介面的冪等性,介面的冪等性實際上就是介面可重複呼叫,在呼叫方多次呼叫的情況下,介面最終得到的結果是一致的。有些介面可以天然的實現冪等性,比如查詢介面,對於查詢來說,你查詢一次和兩次,對於系統來說,沒有任何影響,查出的結果也是一樣。

除了查詢功能具有天然的冪等性之外,增加、更新、刪除都要保證冪等性。那麼如何來保證冪等性呢?

全域性唯一ID

如果使用全域性唯一ID,就是根據業務的操作和內容生成一個全域性ID,在執行操作前先根據這個全域性唯一ID是否存在,來判斷這個操作是否已經執行。如果不存在則把全域性ID,儲存到儲存系統中,比如資料庫、redis等。如果存在則表示該方法已經執行。

從工程的角度來說,使用全域性ID做冪等可以作為一個業務的基礎的微服務存在,在很多的微服務中都會用到這樣的服務,在每個微服務中都完成這樣的功能,會存在工作量重複。另外打造一個高可靠的冪等服務還需要考慮很多問題,比如一臺機器雖然把全域性ID先寫入了儲存,但是在寫入之後掛了,這就需要引入全域性ID的超時機制。

使用全域性唯一ID是一個通用方案,可以支援插入、更新、刪除業務操作。但是這個方案看起來很美但是實現起來比較麻煩,下面的方案適用於特定的場景,但是實現起來比較簡單。

去重表

這種方法適用於在業務中有唯一標的插入場景中,比如在以上的支付場景中,如果一個訂單隻會支付一次,所以訂單ID可以作為唯一標識。這時,我們就可以建一張去重表,並且把唯一標識作為唯一索引,在我們實現時,把建立支付單據和寫入去去重表,放在一個事務中,如果重複建立,資料庫會丟擲唯一約束異常,操作就會回滾。

插入或更新

這種方法插入並且有唯一索引的情況,比如我們要關聯商品品類,其中商品的ID和品類的ID可以構成唯一索引,並且在資料表中也增加了唯一索引。這時就可以使用InsertOrUpdate操作。在mysql資料庫中如下:

insert into goods_category (goods_id,category_id,create_time,update_time) 
values(#{goodsId},#{categoryId},now(),now()) 
on DUPLICATE KEY UPDATE 
 update_time=now()多版本控制

這種方法適合在更新的場景中,比如我們要更新商品的名字,這時我們就可以在更新的介面中增加一個版本號,來做冪等

boolean updateGoodsName(int id,String newName,int version);

在實現時可以如下

update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}狀態機控制

這種方法適合在有狀態機流轉的情況下,比如就會訂單的建立和付款,訂單的付款肯定是在之前,這時我們可以通過在設計狀態欄位時,使用int型別,並且通過值型別的大小來做冪等,比如訂單的建立為0,付款成功為100。付款失敗為99

在做狀態機更新時,我們就這可以這樣控制

update `order` set status=#{status} where id=#{id} and status<#{status}

以上就是保證介面冪等性的一些方法。