主頁 > 軟體設計 > 冪等設計詳解

冪等設計詳解

2022-09-27 08:54:28 軟體設計

導讀

本文主要從研發人員的角度,結合研發人員日常常見的各類業務場景,從經典系統框架的每一層入手分析冪等處理的時機,希望通過這篇文章的分析,讓開發者在日常開發中對冪等的處理不再陌生,抓住導致請求、介面不冪等的本質,在作業中避免再陷入這個陷阱中,

冪等、冪等性這詞,作為一個研發人員是再熟悉不過的,那是否有深入思考過冪等產生的背景、為什么需要冪等,如何做才是冪等的?今天將結合業務場景及請求的程序來分析解決冪等(性)的方法,

1 概念

冪等這個概念,是一個數學上的概念,即:f……(f(f(x))) = f(x),用在計算機領域,指的是系統里的介面或方法對外的一種承諾,使用相同引數對同一資源重復呼叫某個介面或方法的結果與呼叫一次的結果相同,

2 業務場景

從業務場景上來說,如:現在互聯網電商的下單服務,同一個用戶在短時間內呼叫某一個下單服務,只能下單成功一次;銀行賬戶之間的轉賬,A賬戶給B賬戶轉賬,無論系統出現什么問題或故障,也只能轉賬成功一次;前端頁面對相同表單的內容多次向后端發起提交請求,后端只能給出一個相同的結果等都屬于冪等的范疇,

試想一下,如果提供的這些服務不是冪等的,客戶在下單時由于網路不穩定或是連續點了幾次下單按鈕,實際客戶只下了一單,結果系統里給客戶生成了多單,那平臺/商家將是無法承受的,如果被“羊毛黨”盯上,損失是無可估量的;銀行之間的轉賬,A賬戶本來實際給B賬戶只轉了一百萬,結果B賬戶收到了幾百萬,這在業務上是不可接受的,分析這些業務場景,開發者發現,無論是下單服務、轉賬服務還是表單提交都是一個個業務請求,提供這些業務服務的介面或方法都應該保證無論服務是超時、重試或有故障等例外情況,都要滿足業務上的處理結果是正確的,業務上的一次或多次請求,最終的處理結果是一致的,即:在一定時間內,服務的冪等其實就是請求的冪等,

3 架構分析

從系統架構上進行分析,冪等該在哪一層去做,怎么做?

圖1 經典系統框架圖

上圖為一個最常見的經典系統框架圖,Web端發起一個請求到后端,冪等該在哪一層來處理呢?不妨一層一層地分析,

Nginx是否需要做冪等,Nginx的主要功能是做Web服務器、反向代理、負載均衡等,把請求轉發到后端的服務器上,本身不參與具體的業務,所以Nginx是不需要做冪等處理的;Gateway是負責權限校驗、安全防御、認證鑒權、流量控制、協議轉換、日志審計、監控等,本身也不含對任何業務的處理,所以其也不需要做冪等處理;Service層通常是對業務邏輯進行處理、編排,可能會改變資料,但對于資料的改變結果,最終也還是需要通過資料訪問層,寫入到資料庫,所以Service層也不需要做資料冪等;DAO層主要是和資料庫互動,把Service層的結果寫入資料庫,對Service層提供讀取、寫入資料庫的功能,

在寫入資料庫的時候,針對每一次的寫入,可能回傳不同的結果,此時就需要按場景進行具體的分析對待;DataBase層,主要提供資料的存盤,并不參與具體的業務邏輯計算,所以,通過對該架構的每一層的功能分析,得出對于請求的冪等處理,需要在DAO層做處理,以便保證多次請求和一次請求的結果是一致的,

4 資料庫操作分析

通過上面的分析,得出冪等需要在DAO層來處理,再進一步分析,得出DAO層的操作主要就是CRUD,下面逐一對每一種操作分析是否需要做冪等,以及怎么做,

R(read):對應的操作SQL陳述句為select,只要查詢條件不變,在一定的時間內,執行一次和執行多次回傳的結果肯定是相同的,所以其本身是冪等的,不需要再做處理,

select * from user where id = 1;

查詢一次或多次結果是一致的,所以是冪等的,

C(create):對應的操作SQL陳述句為insert,此時,需要分情況,如果用到的資料庫主鍵為資料庫自增,不考慮業務主鍵防重的情況下,每一次寫入資料庫就不是冪等的,所以為了保證冪等,需要在資料insert前做業務防重或是在資料庫表上對業務主鍵加唯一索引,如果資料庫主鍵不是自增,是由業務系統寫入的,需要在業務系統里把資料庫主鍵和業務主鍵做一對一映射,或是由獨立服務提供資料庫主鍵和業務主鍵的映射關系,保證多次請求獲取到的資料庫主鍵和業務主鍵是一致的,確保寫入資料庫操作是冪等的,綜合來說,就是相同的資料多次寫入資料庫后,能否保證只有一條資料,

insert into user (id,age,sex,ts) values(1,10,‘male’,2021-07-20 10:22:23);

U(update):對應的操作SQL陳述句為update,更新操作時,一定是要用絕對值進行更新操作,而不要用相對值進行更新,相對值更新可能導致更新操作不冪等,

冪等:

update user set age = 10 where id = 1;

非冪等:

update user set age++ where id = 1;

D(delete):對應的操作SQL陳述句為delete,洗掉操作時,如果洗掉的是一個范圍,生產上最好是禁止該類操作;比較推薦的做法是把按范圍操作洗掉轉換為先按范圍查詢,再按查詢的主鍵進行洗掉,而且按范圍洗掉的操作不是冪等的,

冪等:

delete from user where id = 1;

非冪等:該類操作要禁止,

delete from user where id in (select id from user order by id desc limit 10);

5 常見業務場景

保證冪等的實作方式有多種,此處例舉幾類常見的業務場景,在實際應用中,根據業務場景進行選用,

圖2 頁面token機制處理流程

  1. 前端頁面提交時,頁面token機制,進入頁面時,從服務器獲取token,在服務器端把token進行存盤,提交時把token帶到服務器端進行驗證;常見的處理流程如下:
  2. 樂觀鎖機制,使用資料庫的版本號實作樂觀鎖,資料庫更新時,判斷版本號是否與查詢時保持一致,一致更新成功,否則更新失敗;
  3. select+insert,資料寫入前,先查詢資料是否存在,存在直接回傳,不存在則寫入資料,保證寫入資料庫的資料正確性;常用于并發不高的一些后臺系統或是防止任務的重復執行;
  4. 悲觀鎖機制,一般id為主鍵或唯一索引,僅鎖定當前記錄;
  5. select * from table where id = '1234' for update;
  6. 去重表,每一次寫入或更新業務表時,先查詢去重表是否已經存在記錄,再操作業務表,
  7. 資料庫唯一索引,為業務表建立唯一索引,避免業務資料多次寫入;
  8. 狀態機,業務狀態在變更之前是有條件的,必須按設定的狀態條件進行更新;

在實際開發中,保證提供的介面或服務的冪等(性),是一個最基本的技術要求,希望通過該分析,能對還未理解冪等(性)的研發人員有所幫助,

 

作者:廖宗雄

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/509640.html

標籤:架構設計

上一篇:微服務設計(四)---微服務網關與鏈路追蹤

下一篇:返回列表

標籤雲
其他(145333) Python(37296) JavaScript(24909) Java(16484) C(14967) 區塊鏈(8236) C#(7957) AI(7469) 爪哇(7405) html(6776) MySQL(6728) 基礎類(6313) sql(6084) 熊猫(6051) PHP(5787) 数组(5741) R(5307) 反应(5188) Linux(5185) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4415) 数据框(4310) css(4249) 节点.js(4029) C語言(3288) json(3241) 列表(3120) C++語言(3117) 扑(3085) 安卓(2997) 打字稿(2957) VBA(2784) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2401) ASP.NET(2364) MongoDB(2317) 麻木的(2285) 正则表达式(2232) 字典(2211) 循环(2197) 迅速(2174) 擅长(2159) 镖(2150) 功能(1967) Web開發(1951) python-3.x(1918) 弹簧靴(1911) xml(1884) for循环(1841) 谷歌表格(1837) Unity3D(1824) PostgreSQL(1808) .NET技术(1800) 網絡通信(1793) .NETCore(1792) 蟒蛇-3.x(1774)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 冪等設計詳解

    本文主要從研發人員的角度,結合研發人員日常常見的各類業務場景,從經典系統框架的每一層入手分析冪等處理的時機。希望通過這篇文章的分析,讓開發者在日常開發中對冪等的處理不再陌生。抓住導致請求、介面不冪等的本質,在作業中避免再陷入這個陷阱中。 ......

    uj5u.com 2022-09-27 08:54:28 more
  • 微服務設計(四)---微服務網關與鏈路追蹤

    一、微服務網關概述 如下圖: 不同的微服務一般會有不同的網路地址,客戶端在訪問這些微服務時必須記住幾十甚至幾百個地址,這對于客戶端方來說太復雜也難以維護。如果讓客戶端直接與各個微服務通訊,可能會有很多問題: 客戶端會請求多個不同的服務,需要維護不同的請求地址,增加開發難度 在某些場景下存在跨域請求的 ......

    uj5u.com 2022-09-26 07:27:15 more
  • 微服務設計(三)---服務呼叫Feign及服務熔斷機制Hystrix

    一 、Ribbon概述 Netflixfa 發布的一個負載均衡器,有助于控制HTTP和TCP客戶端行為。在SpringCloud中,Ribbon提供了客戶端負載均衡的功能,Ribbon自動從服務注冊中心Eureka中讀取到的服務提供者的串列資訊(動態獲取服務串列方式),在呼叫服務節點提供的服務時,基 ......

    uj5u.com 2022-09-26 07:26:45 more
  • 初識設計模式 - 原型模式

    簡介 對于大部分系統來說,創建物件包括申請記憶體、給成員變數賦值等程序,這些操作耗費的時間基本可以忽略不計。 如果物件中的資料需要經過復雜的計算才能得到(比如排序、計算哈希值),或者需要從 RPC、網路、資料庫、檔案系統等非常慢速的 IO 中讀取,這其中耗費的時間有時是無法容忍的。 如果物件的創建成本 ......

    uj5u.com 2022-09-26 07:26:29 more
  • 建造者模式(創建型)

    建造者模式 介紹 建造者模式注重的是部件構建的程序,意在通過一步一步地精確構造出一個復雜的物件。 可以將建造者模式理解為,假設我們有一個物件需要建立,這個物件是由多個組件(Component)組合而成,每個組件的建立都比較復雜,但運用組件來建立所需的組件物件非常簡單,所以我們就可以將構建復雜組件的步 ......

    uj5u.com 2022-09-26 07:26:21 more
  • 初識設計模式 - 原型模式

    簡介 對于大部分系統來說,創建物件包括申請記憶體、給成員變數賦值等程序,這些操作耗費的時間基本可以忽略不計。 如果物件中的資料需要經過復雜的計算才能得到(比如排序、計算哈希值),或者需要從 RPC、網路、資料庫、檔案系統等非常慢速的 IO 中讀取,這其中耗費的時間有時是無法容忍的。 如果物件的創建成本 ......

    uj5u.com 2022-09-26 07:26:05 more
  • 建造者模式(創建型)

    建造者模式 介紹 建造者模式注重的是部件構建的程序,意在通過一步一步地精確構造出一個復雜的物件。 可以將建造者模式理解為,假設我們有一個物件需要建立,這個物件是由多個組件(Component)組合而成,每個組件的建立都比較復雜,但運用組件來建立所需的組件物件非常簡單,所以我們就可以將構建復雜組件的步 ......

    uj5u.com 2022-09-26 07:25:56 more
  • 微服務設計(四)---微服務網關與鏈路追蹤

    一、微服務網關概述 如下圖: 不同的微服務一般會有不同的網路地址,客戶端在訪問這些微服務時必須記住幾十甚至幾百個地址,這對于客戶端方來說太復雜也難以維護。如果讓客戶端直接與各個微服務通訊,可能會有很多問題: 客戶端會請求多個不同的服務,需要維護不同的請求地址,增加開發難度 在某些場景下存在跨域請求的 ......

    uj5u.com 2022-09-26 07:25:11 more
  • 微服務設計(三)---服務呼叫Feign及服務熔斷機制Hystrix

    一 、Ribbon概述 Netflixfa 發布的一個負載均衡器,有助于控制HTTP和TCP客戶端行為。在SpringCloud中,Ribbon提供了客戶端負載均衡的功能,Ribbon自動從服務注冊中心Eureka中讀取到的服務提供者的串列資訊(動態獲取服務串列方式),在呼叫服務節點提供的服務時,基 ......

    uj5u.com 2022-09-26 07:24:40 more
  • 工廠模式總結——三個工廠

    在創建型模式中,工廠模式是我們日常使用最為頻繁的設計模式之一。工廠模式可細分為簡單工廠模式、工廠方法模式、抽象工廠模式。 簡單工廠模式 模式簡介 簡單工廠模式:根據引數回傳不同類的實體,這些類通常具有共同的父類。 簡單工廠模式包括三個角色: 工廠 (Factory):用于創建所需產品,提供靜態工廠方 ......

    uj5u.com 2022-09-25 08:03:15 more