建站
咨詢
售后
建站咨詢
新聞中心
業(yè)務(wù)背景
首先給大家說說，假如說要是我們線上系統(tǒng)的核心接口要是沒有冪等性保障機(jī)制的話，可能會出現(xiàn)什么情況?
成都創(chuàng)新互聯(lián)公司是專業(yè)的烏拉特后網(wǎng)站建設(shè)公司，烏拉特后接單;提供網(wǎng)站制作、成都網(wǎng)站建設(shè),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行烏拉特后網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
其實(shí)非常簡單，假設(shè)你有一個系統(tǒng)，他有一個接口，這個接口接受請求的時候假設(shè)會在數(shù)據(jù)庫里插入一條數(shù)據(jù)，正常情況下一個用戶對這個接口發(fā)起一次請求應(yīng)該就只有一條數(shù)據(jù)，結(jié)果可能某一天你會發(fā)現(xiàn)這個用戶通過這個接口插入了多條數(shù)據(jù)。
如下圖 1 所示：
圖 1
初版防重代碼
那么為什么會這樣呢?其實(shí)我們一般這類系統(tǒng)接口，但凡是寫的稍微好一點(diǎn)的，都會在接口里加入防重代碼。
就是會有代碼判斷一下，當(dāng)前你要寫入的這條數(shù)據(jù)是否存在，如果他要是不存在的話，就會進(jìn)行插入，但是如果他存在的話就不會允許你重復(fù)插入的。
這種防重代碼如下所示：
public void business(Request request) {
// 1、先根據(jù)請求參數(shù)在db里查詢一下這條數(shù)據(jù)
Data data = findData(request);
// 2、如果這條數(shù)據(jù)在db里已經(jīng)存在了，此時就直接返回了
if(data != null) {
return;
}
// 3、如果要是這條數(shù)據(jù)在db里不存在，此時就會執(zhí)行數(shù)據(jù)插入邏輯了
insertData(request);
}
結(jié)合上面這段代碼的防重邏輯，我們可以看下圖 2 的運(yùn)行邏輯展示：
圖 2
在插入數(shù)據(jù)之前一定會先根據(jù)請求參數(shù)查詢這條數(shù)據(jù)，如果查詢到了，則此時直接返回不會重復(fù)插入，但是如果沒有查詢到這條數(shù)據(jù)，則此時會插入這條數(shù)據(jù)。
那么大家可能問題來了，那既然都已經(jīng)有這個防重邏輯了，即使你用相同的請求參數(shù)重復(fù)多次調(diào)用這個接口插入數(shù)據(jù)，也不應(yīng)該重復(fù)插入數(shù)據(jù)啊!
按說確實(shí)是這樣子的，但是凡事總有例外，那就是大名鼎鼎的瞬時重試+多線程并發(fā)問題。
瞬時重試+多線程并發(fā)問題分析
下面我們給大家解釋一下，在上述的代碼防重邏輯下，如果要是短時間內(nèi)用戶用相同的請求參數(shù)重復(fù)的發(fā)起了兩次請求，為什么會穿透防重邏輯，在數(shù)據(jù)庫里插入兩條一樣的數(shù)據(jù)。
大家要打起且精神來，仔細(xì)來看這個過程了， 首先用戶可能會因?yàn)檫^于激動、手抖或者是網(wǎng)絡(luò)抽風(fēng)等各種原因，在一瞬間發(fā)起兩次請求參數(shù)完全相同的請求。
如下圖 3 所示：
圖 3
接著呢，這兩個請求到了我們的系統(tǒng)后，其實(shí)是分別由一個線程來處理的，不管你是用 tomcat 部署提供的 controller 接口，還是基于 dubbo 提供的 rpc 接口，其實(shí)每個請求過來都是由一個獨(dú)立的線程來處理的。
如下圖 4 所示：
圖 4
接著呢，這兩個線程會并發(fā)的運(yùn)行相同的一段代碼邏輯，就是先根據(jù)請求參數(shù)查詢這條數(shù)據(jù)是否存在，存在就返回，不存在就進(jìn)行插入。
這個時候可能會出現(xiàn)一個問題，因?yàn)槭嵌嗑€程并發(fā)，所以很可能這兩個線程會同時執(zhí)行數(shù)據(jù)查詢邏輯，但是他們倆同時執(zhí)行數(shù)據(jù)查詢邏輯的時候，有一個問題，那就是此時數(shù)據(jù)庫里沒數(shù)據(jù)啊!
所以說，這兩個線程并發(fā)運(yùn)行，完全可能會同時發(fā)現(xiàn)從數(shù)據(jù)庫里查詢出來的數(shù)據(jù)是空的。
如下圖 5 所示：
圖 5
然后這個時候，兩個線程既然發(fā)現(xiàn)自己查詢到的數(shù)據(jù)都是空的，那當(dāng)然都可以去插入數(shù)據(jù)了。
所以此時這兩個線程會基于這個請求參數(shù)分別插入一條數(shù)據(jù)，而這條數(shù)據(jù)其實(shí)對于業(yè)務(wù)來說是完全重復(fù)的，因?yàn)檎埱髤?shù)是完全相同的。
如下圖 6 所示：
圖 6
這個時候就會導(dǎo)致本次數(shù)據(jù)重復(fù)問題了，針對這種情況，我們一般把這種接口稱之為沒有冪等性。
因?yàn)槿绻粋€接口是有冪等性的，其實(shí)對于這個接口如果說用相同的參數(shù)發(fā)起請求，那肯定是只會有一條數(shù)據(jù)，不可能會有重復(fù)數(shù)據(jù)的，這才叫做冪等性。
而現(xiàn)在的問題是，這個接口用相同的請求參數(shù)發(fā)起多次，結(jié)果數(shù)據(jù)有重復(fù)了，此時接口就沒有冪等性。
數(shù)據(jù)庫唯一索引實(shí)現(xiàn)冪等
針對上述這種接口冪等問題，其實(shí)比較簡單的一種解決方案，就是基于我們依賴的數(shù)據(jù)庫去實(shí)現(xiàn)冪等。
也就是說，用數(shù)據(jù)庫的唯一索引來實(shí)現(xiàn)即可，如果我們要是基于請求中的某一個或者多個業(yè)務(wù)字段組成一個唯一索引，那么其實(shí)你要往數(shù)據(jù)庫中用相同參數(shù)插入重復(fù)數(shù)據(jù)，那就是不可能的。
因?yàn)閿?shù)據(jù)庫層面就會阻止你插入的，唯一索引會確保這一點(diǎn)，你要重復(fù)插入，他就會拋異常。
如下 7 所示：
圖 7
分布式鎖實(shí)現(xiàn)冪等
但是很多時候我們會發(fā)現(xiàn)一個問題，那就是我們可能不一定說每次都可以依賴數(shù)據(jù)庫的 唯一索引實(shí)現(xiàn)這種冪等性。
因?yàn)橛锌赡苣阍跇I(yè)務(wù)邏輯里，除了依賴數(shù)據(jù)庫以外，還依賴了別的服務(wù)接口，或者是 elasticsearch、redis 等多種數(shù)據(jù)存儲，也可能是依賴了數(shù)據(jù)庫中的多張表里的數(shù)據(jù)，你不可能每張表都做一個唯一索引來確保冪等性。
所以對于有復(fù)雜業(yè)務(wù)邏輯的接口來說，要確保冪等性，往往需要引入一個關(guān)鍵組件，那就是分布式鎖。
所謂的分布式鎖，意思就是依賴外部的某個系統(tǒng)來加一把鎖，鎖加了以后后續(xù)還可以釋放這把鎖，現(xiàn)在比較常見的分布式鎖實(shí)現(xiàn)主要是依賴 redis 和 zookeeper 這兩個來實(shí)現(xiàn)的，我們這里就以 redis 分布式鎖來舉例說明。
先往簡單了說，我們可以在接口的入口代碼處，基于 redis 加一把分布式的鎖，這個時候只有一個線程可以成功加鎖。
加鎖之后，就這一個線程就可以去查詢這條數(shù)據(jù)是否存在，如果不存在，就可以插入一條數(shù)據(jù)進(jìn)去，然后再釋放鎖，在這個過程中，另外一個線程因?yàn)楂@取不到 redis 分布式鎖，所以只能干等著。
如下圖 8 所示：
圖 8
等第一個線程加鎖，然后查詢數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)不存在，接著插入一條數(shù)據(jù)，最后釋放鎖之后，接著第二個線程就才能得到機(jī)會再次加鎖，接著第二個線程加鎖后查詢數(shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)已經(jīng)存在了，此時他就會直接返回，不會重復(fù)插入數(shù)據(jù)了。
如下圖 9 所示：
圖 9
如上圖，大家可以發(fā)現(xiàn)，只要在核心接口的入口處加一把分布式鎖，就可以實(shí)現(xiàn)多線程并發(fā)下，復(fù)雜業(yè)務(wù)邏輯不會被重復(fù)執(zhí)行了，而且不依賴數(shù)據(jù)庫某個表的唯一索引，只要基于 redis 實(shí)現(xiàn)加鎖和釋放鎖就可以了。
而至于 redis 分布式鎖是如何實(shí)現(xiàn)的，就不在本文的討論中了，我們這次主要是給大家先分析一下線上系統(tǒng)接口的冪等問題，當(dāng)沒有冪等性的時候，接口是如何在多線程并發(fā)場景下出現(xiàn)數(shù)據(jù)重復(fù)問題的。
總結(jié)
然后我們分析了，如果要是基于數(shù)據(jù)庫表加一個唯一索引，就可以實(shí)現(xiàn)接口冪等了 ，可是如果業(yè)務(wù)邏輯過于復(fù)雜，有很多數(shù)據(jù)存儲，或者涉及很多表，此時就不能單單依賴一個唯一索引了，需要依靠在接口入口處加分布式鎖，然后才可以解決復(fù)雜接口的冪等性。
分享文章：Java多線程并發(fā)數(shù)據(jù)錯亂了，接口冪等性如何設(shè)計(jì)？
文章出自：http://www.dlmjj.cn/article/coshoee.html
