【轉載】高併發的核心技術-冪等的實現方案
原文地址:http://blog.csdn.net/rdhj5566/article/details/50646599
一、背景
我們實際系統中有很多操作,是不管做多少次,都應該產生一樣的效果或返回一樣的結果。
例如:
1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。
2. 我們發起一筆付款請求,應該只扣使用者賬戶一次錢,當遇到網路重發或系統bug重發,也應該只扣一次錢;
3. 傳送訊息,也應該只發一次,同樣的簡訊發給使用者,使用者會哭的;
4. 建立業務訂單,一次業務請求只能建立一個,建立多個就會出大問題。
等等很多重要的情況,這些邏輯都需要冪等的特性來支援。
二、冪等性概念
冪等(idempotent、idempotence)是一個數學與計算機學概念,常見於抽象代數中。
在程式設計中.一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函式,或冪等方法,是指可以使用相同引數重複執行,並能獲得相同結果的函式。這些函式不會影響系統狀態,也不用擔心重複執行會對系統造成改變。例如,“getUsername()和setTrue()”函式就是一個冪等函式.
更復雜的操作冪等保證是利用唯一交易號(流水號)實現.
我的理解:冪等就是一個操作,不論執行多少次,產生的效果和返回的結果都是一樣的
三、技術方案
1. 查詢操作
查詢一次和查詢多次,在資料不變的情況下,查詢結果是一樣的。select是天然的冪等操作
2. 刪除操作
刪除操作也是冪等的,刪除一次和多次刪除都是把資料刪除。(注意可能返回結果不一樣,刪除的資料不存在,返回0,刪除的資料多條,返回結果多個)
3.唯一索引,防止新增髒資料
比如:支付寶的資金賬戶,支付寶也有使用者賬戶,每個使用者只能有一個資金賬戶,怎麼防止給使用者建立資金賬戶多個,那麼給資金賬戶表中的使用者ID加唯一索引,所以一個使用者新增成功一個資金賬戶記錄
要點:
唯一索引或唯一組合索引來防止新增資料存在髒資料
(當表存在唯一索引,併發時新增報錯時,再查詢一次就可以了,資料應該已經存在了,返回結果即可)
4. token機制,防止頁面重複提交
業務要求:
頁面的資料只能被點選提交一次
發生原因:
由於重複點選或者網路重發,或者nginx重發等情況會導致資料被重複提交
解決辦法:
叢集環境:採用token加redis(redis單執行緒的,處理需要排隊)
單JVM環境:採用token加redis或token加jvm記憶體
處理流程:
1. 資料提交前要向服務的申請token,token放到redis或jvm記憶體,token有效時間
2. 提交後後臺校驗token,同時刪除token,生成新的token返回
token特點:
要申請,一次有效性,可以限流
注意:redis要用刪除操作來判斷token,刪除成功代表token校驗通過,如果用select+delete來校驗token,存在併發問題,不建議使用
5. 悲觀鎖
獲取資料的時候加鎖獲取
select * from table_xxx where id='xxx' for update;
注意:id欄位一定是主鍵或者唯一索引,不然是鎖表,會死人的
悲觀鎖使用時一般伴隨事務一起使用,資料鎖定時間可能會很長,根據實際情況選用
6. 樂觀鎖
樂觀鎖只是在更新資料那一刻鎖表,其他時間不鎖表,所以相對於悲觀鎖,效率更高。
樂觀鎖的實現方式多種多樣可以通過version或者其他狀態條件:
1). 通過版本號實現
update table_xxx set name=#name#,version=version+1 where version=#version#
如下圖(來自網上):
2). 通過條件限制
update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
要求:quality-#subQuality# >= ,這個情景適合不用版本號,只更新是做資料安全校驗,適合庫存模型,扣份額和回滾份額,效能更高
注意:樂觀鎖的更新操作,最好用主鍵或者唯一索引來更新,這樣是行鎖,否則更新時會鎖表,上面兩個sql改成下面的兩個更好
update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0
7. 分散式鎖
還是拿插入資料的例子,如果是分佈是系統,構建全域性唯一索引比較困難,例如唯一性的欄位沒法確定,這時候可以引入分散式鎖,通過第三方的系統(redis或zookeeper),在業務系統插入資料或者更新資料,獲取分散式鎖,然後做操作,之後釋放鎖,這樣其實是把多執行緒併發的鎖的思路,引入多多個系統,也就是分散式系統中得解決思路。
要點:某個長流程處理過程要求不能併發執行,可以在流程執行之前根據某個標誌(使用者ID+字尾等)獲取分散式鎖,其他流程執行時獲取鎖就會失敗,也就是同一時間該流程只能有一個能執行成功,執行完成後,釋放分散式鎖(分散式鎖要第三方系統提供)
8. select + insert
併發不高的後臺系統,或者一些任務JOB,為了支援冪等,支援重複執行,簡單的處理方法是,先查詢下一些關鍵資料,判斷是否已經執行過,在進行業務處理,就可以了
注意:核心高併發流程不要用這種方法
9. 狀態機冪等
在設計單據相關的業務,或者是任務相關的業務,肯定會涉及到狀態機(狀態變更圖),就是業務單據上面有個狀態,狀態在不同的情況下會發生變更,一般情況下存在有限狀態機,這時候,如果狀態機已經處於下一個狀態,這時候來了一個上一個狀態的變更,理論上是不能夠變更的,這樣的話,保證了有限狀態機的冪等。
注意:訂單等單據類業務,存在很長的狀態流轉,一定要深刻理解狀態機,對業務系統設計能力提高有很大幫助
10. 對外提供介面的api如何保證冪等
如銀聯提供的付款介面:需要接入商戶提交付款請求時附帶:source來源,seq序列號
source+seq在資料庫裡面做唯一索引,防止多次付款,(併發時,只能處理一個請求)
重點:
對外提供介面為了支援冪等呼叫,介面有兩個欄位必須傳,一個是來源source,一個是來源方序列號seq,這個兩個欄位在提供方系統裡面做聯合唯一索引,這樣當第三方呼叫時,先在本方系統裡面查詢一下,是否已經處理過,返回相應處理結果;沒有處理過,進行相應處理,返回結果。注意,為了冪等友好,一定要先查詢一下,是否處理過該筆業務,不查詢直接插入業務系統,會報錯,但實際已經處理了。
總結:
冪等性應該是合格程式設計師的一個基因,在設計系統時,是首要考慮的問題,尤其是在像支付寶,銀行,網際網路金融公司等涉及的都是錢的系統,既要高效,資料也要準確,所以不能出現多扣款,多打款等問題,這樣會很難處理,使用者體驗也不好
相關推薦
【轉載】高併發的核心技術-冪等的實現方案
原文地址:http://blog.csdn.net/rdhj5566/article/details/50646599 一、背景 我們實際系統中有很多操作,是不管做多少次,都應該產生一樣的效果或返回一樣的結果。 例如: 1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。 2. 我們發起
【轉載】高併發解決:常見併發同步案例分析
案例一:訂票系統案例,某航班只有一張機票,假定有1w個人開啟你的網站來訂票,問你如何解決併發問題(可擴充套件到任何高併發網站要考慮 的併發讀寫問題) 問題,1w個人來訪問,票沒出去前要保證大家都能看到有票,不可能一個人在看到票的時候別人就不能
【轉載】分散式系統中的冪等性
我們的系統大多拆分為分散式SOA,或者微服務,一套系統中包含了多個子系統服務,而一個子系統服務往往會去呼叫另一個服務,而服務呼叫服務無非就是使用RPC通訊或者restful,既然是通訊,那麼就有可能再伺服器處理完畢後返回結果的時候掛掉,這個時候使用者端發現很久沒有反應,那麼
【總結】高併發-冪等實現方案
一、背景 我們實際系統中有很多操作,是不管做多少次,都應該產生一樣的效果或返回一樣的結果。 例如: 1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。 2. 我們發起一筆付款請求,應該只扣使用者賬戶一次錢,當遇到網路重發或系統b
高併發的核心技術-冪等的實現方案
原文地址:http://blog.csdn.net/rdhj5566/article/details/50646599 一、背景 我們實際系統中有很多操作,是不管做多少次,都應該產生一樣的效果或返回一樣的結果。 例如: 1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。 2.
【轉載】oracle閃回技術詳解之閃回drop(神奇的flashback)
寫在前面:刪庫跑路,相信這是絕大多數程式設計師會經常聽到的一個詞。俗話說:常在河邊走,哪有不溼鞋,作為經常和資料打交道的程式設計師也好,運維實施也好,有時難免會出現資料誤刪除,誤操作等情況。如果你是一個oracle使用者,那麼你如果知道這些關於資料閃回恢復的基本知識,或許可以幫你在出現類似情況的時候解決很多問
【轉載】Java併發程式設計:Lock
Java併發程式設計:Lock 在上一篇文章中我們講到了如何使用關鍵字synchronized來實現同步訪問。本文我們繼續來探討這個問題,從Java 5之後,在java.util.concurrent.locks包下提供了另外一種方式來實現同步訪問,那就是Lock。
高併發核心技術 - 訂單與庫存[轉]
轉自:http://blog.51cto.com/4925054/2088726 2018-03-19 20:57:05 高併發核心技術 - 訂單與庫存 問題: 一件商品只有100個庫存,現在有1000或者更多的使用者來購買,每個使用者計劃同時購買1個到幾個不等商品。如何保證庫存
高併發核心技術,訂單與庫存--如何防止超發,少發?
參考連結:http://jblog.top/article/details/255453解決方案:採用redis事務控制。如果直接用redis的incr、decr等命令,個人理解就是將資料庫的壓力前移到了redis,僅僅是提升了效能,沒有從根本上解決問題。如果在獲取庫存後,假
【Linux】高併發伺服器模型(多程序模型和多執行緒模型)
多程序併發伺服器 使用多程序併發伺服器時要考慮以下幾點: 1. 父程序最大檔案描述個數(父程序中需要close關閉accept返回的新檔案描述符) 2. 系統內建立程序個數(與記憶體大小相關)
高併發核心技術
高併發核心技術之 - 冪等性 1. 什麼是冪等性 冪等性就是指:一個冪等操作任其執行多次所產生的影響均與一次執行的影響相同。 用
【轉載】mysql 百萬級記錄時查詢優化方案
1.對查詢進行優化,應儘量避免全表掃描,首先應考慮在 where 及 order by 涉及的列上建立索引。 2.應儘量避免在 where 子句中對欄位進行 null 值判斷,否則將導致引擎放棄使用索引而進行全表掃描,如: select id from t w
【轉載】tomcat埠被佔用問題完美解決方案!
https://www.cnblogs.com/hjchoset/p/6027589.html 啟動Tomcat伺服器報錯:Several ports (8005, 8080, 8009) requi
高併發系統資料冪等的解決方案,併發冪等解決方案
http://www.bkjia.com/MsSql/1151376.html 前言 在系統開發過程中,經常遇到資料重複插入、重複更新、訊息重發傳送等等問題,因為應用系統的複雜邏輯以及網路互動存在的不確定性,會導致這一重複現象,但是有些邏輯是需要有冪等特性的,否則造成
高併發實戰之冪等處理
一、背景 1. 前端重複提交選中的資料,應該後臺只產生對應這個資料的一個反應結果。 2. 我們發起一筆付款請求,應該只扣使用者賬戶一次錢,當遇到網路重發或系統bug重發,也應該只扣一次錢; 3. 傳送訊息,也應該只發一次,同樣的簡訊發給使用者,使用者會哭的; 4. 建立業務訂單,一次業務請求只能建立一
【轉載】常用資料增強方法總結及實現
【參考資料】論文:ImageNet Classification with Deep Convolutional Neural Networks【常用方法】1、Color Jittering:對顏色的資料增強:影象亮度、飽和度、對比度變化(此處對色彩抖動的理解不知是否得當);
【轉載】jdk、jre、jvm等名詞解釋
摘自網路。 JDK, JRE 和JVM是Java程式語言的核心概念。儘管它們看起來差不多,作為程式設計師我們也不怎麼關心這些概念,但是它們是不同的針對特定目的的產品。這是一道常見的java面試題,而本文則會一一解釋這些概念並給出它們之間的區別。 Java 開發工具包
【轉載】Android 使用開源庫StickyGridHeaders來實現帶sections和headers的GridView顯示本地圖片效果
StickyGridHeaders是一個自定義GridView帶sections和headers的Android庫,sections就是GridView item之間的分隔,headers就是固定在GridView頂部的標題,類似一些Andro
【轉載】史上最全:TensorFlow 好玩的技術、應用和你不知道的黑科技
tube map 高性能 知識 seq 出現 執行時間 mes lex 【導讀】TensorFlow 在 2015 年年底一出現就受到了極大的關註,經過一年多的發展,已經成為了在機器學習、深度學習項目中最受歡迎的框架之一。自發布以來,TensorFlow 不斷在完善並增加新
【轉載】快速冪講解
這一 lan nbsp 進制 pre 去掉 實現 clas done 轉載自:cxcxcxc 快速冪講解 快速冪這個東西比較好理解,但實現起來到不老好辦,記了幾次老是忘,今天把它系統的總結一下防止忘記。 首先