一、單機模式下高并發(fā)問題

前提：先寫一個減扣數(shù)據(jù)庫產品數(shù)量的一個接口作為測試。

拿以前springboot整合布隆過濾網(wǎng)篇的一個接口直接做改造：假設編號為2的蘋果庫存還有一個，現(xiàn)在有個接口去買這個蘋果并生成訂單號以便于后期支付，得到如下：

1、數(shù)據(jù)表：

2、接口

通過jmeter模擬一秒鐘有100個用戶購買這個蘋果，結果會是什么？

會發(fā)現(xiàn)直接賣爆了，一個蘋果被賣了幾十單。怎么解決這個并發(fā)問題呢？

PS：java提供了鎖來處理 

1、樂觀鎖

CAS先比較再交換，Java中提供了Atomic開頭的類，例如AtomicInteger、AtomicLong、AtomicReference等原子類都是此思想來支持CAS操作的。進行如下改造，來實現(xiàn)先比較在修改值的方式解決該問題。其實就是在把cas想做是一個原子操作。改造方式就是例如給商品表增加一個字段用來表示該次原子性操作時，他應該是什么值，若是則修改，不然就不修改。如下：

增加一個number字段，原理就是每次修改時帶上這個number條件，而每次減少count后修改number的值（原子性）第一個請求的用戶這樣處理，其他同時查到這個訂單的其他用戶，在減少count時根據(jù)number條件卻查不到這個訂單了從而無法再生成訂單。代碼如下：

繼續(xù)jmeter測試，再看看結果如何？

發(fā)現(xiàn)通過這種方式的確實現(xiàn)了防止超賣的現(xiàn)象。 

優(yōu)點：不用加鎖，不會阻塞其他線程，性能相比較好。缺點：需要增加表字段，并且由于是在數(shù)據(jù)庫層面保持原子性可能導致多事務操作操作同一數(shù)據(jù)時導致沖突，引起數(shù)據(jù)一致性問題。

結論：所以在并發(fā)較少的情況下可以使用樂觀鎖方式。

2、悲觀鎖

將通過下面兩種鎖來進行演示。

2.1、synchronized鎖

改造代碼如下：

通過測試得出： 

發(fā)現(xiàn)實現(xiàn)了防止超賣，但是synchronized鎖是基于jvm層面的，因此并不適用于集群模式。集群模式會涉及到一個服務的多實例，就會有多個jvm，synchronized只能保證當前實例在當前jvm下的原子性操作。

我們用idea模擬一個集群來進行測試，如下：

執(zhí)行一下jmeter，看看結果是什么？

我們可以看到模擬的每一個機器都搶到了一個，那依舊完犢子了呀。

結論：集群模式下synchronized不可取。

2.2、Lock鎖

相比synchronized而言，這個鎖是方法，而synchronized是關鍵字。使用lock的實現(xiàn)ReentrantLock

改造代碼如下：

繼續(xù)在模擬集群下進行測試，結果如下：

結果和synchronized效果一樣，只有在單機模式下可以保證沒問題，而集群模式下依然會出現(xiàn)問題。

結論：集群模式下Lock鎖不可取。

二、集群模式下高并發(fā)問題

上面講了單機模式下可以采用的方式解決并發(fā)問題，但是有些方式在集群模式下就不可用了，下面就試一下在集群模式下依舊可以解決并發(fā)問題的方法。

還是先看看不做任何處理的集群下進行搶商品是什么情況？

簡直是炸裂，這樣上線不被領導懟著鼻子。

那我們怎么改造呢？我們引入Redisson。

我們直接使用前面整合布隆過濾網(wǎng)的demo，就不講整合Redisson了，已經講過了，直接這里使用。

改造后的代碼如下：

jmeter執(zhí)行后的結果如下：

三臺機器只有一臺搶到了一個蘋果，達到了目的。Redisson的這個分布式鎖的使用也很簡單，如果服務掛掉，無法執(zhí)行final的代碼會如何，如下看看：

我們打個斷點假設服務在獲取鎖后服務掛了，redis如下：

可10秒后，如下：

鎖已經過期失效不見了。因此并不會導致死鎖的發(fā)生，這個分布式鎖的具體實現(xiàn)大佬們可以評論區(qū)交流談論或者后面再繼續(xù)說。

以上就是SpringBoot項目上高并發(fā)問題的解決方案的詳細內容，更多關于SpringBoot高并發(fā)的資料請關注腳本之家其它相關文章！

最新評論