短影片app原始碼，實現冪等設計的常見方式

短影片app原始碼，實現冪等設計的重要方式

一、取消重試

取消重試有兩種方法，第一是設定重試次數為零，第二是選擇不重試的叢集容錯策略。

<!-- 設定重試次數為零 -->
<dubbo:reference id="helloService" interface="com.java.front.dubbo.demo.provider.HelloService" retries="0" />
<!-- 選擇叢集容錯方案 -->
<dubbo:reference id="helloService" interface="com.java.front.dubbo.demo.provider.HelloService" cluster="failfast" />

二、冪等表

假設短影片app原始碼中使用者支付成功後，支付系統將支付成功訊息，傳送至訊息佇列。物流系統訂閱到這個訊息，準備為這筆訂單建立物流單。
但是訊息佇列可能會重複推送，物流系統有可能接收到多次這條訊息。我們希望達到效果是：無論接收到多少條重複訊息，只能建立一筆物流單。
解決方案是冪等表方案。新建一張冪等表，該表就是用來做冪等，無其它業務意義，有一個欄位名為key建有唯 一索引，這個欄位是冪等標準。
早短影片app原始碼的物流系統訂閱到訊息後，首先嚐試插入冪等表，訂單編號作為key欄位。如果成功則繼續建立物流單，如果訂單編號已經存在則違反唯 一性原則，無法插入成功，說明已經進行過業務處理，丟棄訊息。
這張表資料量會比較大，我們可以透過定時任務對資料進行歸檔，例如只保留7天資料，其它資料存入歸檔表。
還有一種廣義冪等表就是我們可以用Redis替代資料庫，在建立物流單之前，我們可以檢查Redis是否存在該訂單編號資料，同時可以為這類資料設定7天過期時間。

三、狀態機

物流單建立成功後會傳送訊息，短影片app原始碼的訂單系統訂閱到訊息後更新狀態為完成，假設變更是將訂單狀態0更新至狀態1。訂單系統也可能收到多條訊息，可能在狀態已經被更新至狀態1之後，依然收到物流單建立成功訊息。
解決方案是狀態機方案。首先繪製狀態機圖，分析狀態流轉形態。例如經過分析狀態1已經是最終態，那麼即使接收到物流單建立成功訊息也不再處理，丟棄訊息。

四、資料庫鎖

資料庫鎖又可以分為悲觀鎖和樂觀鎖兩種型別，悲觀鎖是在獲取資料時加鎖：

select * from table where col='xxx' for update

樂觀鎖是在更新時加鎖，第一步首先查出資料，資料包含version欄位。第二步進行更新操作，如果此時記錄已經被修改則version欄位已經發生變化，無法更新成功：

update table set xxx,
version = #{version} + 1 
where id = #{id} 
and version = #{version}

以上就是短影片app原始碼，實現冪等設計的重要方式， 更多內容歡迎關注之後的文章