在開發(fā)過程中高并發(fā)問題是很棘手的一個(gè)問題（對于博主這樣的小菜雞來說），當(dāng)我們學(xué)習(xí)redis之前，知道redis是單線程運(yùn)行的所以任務(wù)不會出現(xiàn)線程不安全問題。當(dāng)我們在linux中使用ab來模擬高并發(fā)秒殺時(shí)可能會遇到兩種問題，“超時(shí)和超賣”。

超時(shí)

1.redis連接超時(shí)原因

（1）虛擬機(jī)中的配置問題

我們在測試遠(yuǎn)程連接時(shí)redis連接是否成功時(shí)控制臺可能會報(bào)以下錯誤。
如下所示：

每次看到控制臺紅色的文字我就頭疼。。。

在控制臺中的顯示大概意思是顯示連接超時(shí)導(dǎo)致了失敗。
總結(jié)了以下三條連接失敗原因：

• Linux中的防火墻沒有關(guān)閉而導(dǎo)致失敗。
• redis要打開。
• redis.conf中的bind 127.0.01需要注釋掉，然后 需要修改protected-mode no。

之后如果遇到了以上問題請自行查找。

（2）redis成功連接中模擬在高并發(fā)中的超時(shí)

如圖所示：

2.解決方法

在MySQL中使用jdbc可能會發(fā)現(xiàn)連接超時(shí)問題，所以我們使用了數(shù)據(jù)庫連接池來解決問題，例如druid、c3p0等等。同理我們在redis中也可以同樣使用數(shù)據(jù)庫連接池。
節(jié)省每次連接redis服務(wù)帶來的消耗，把連接好的實(shí)例反復(fù)利用。

通過參數(shù)管理連接的行為

直接上記事本代碼！

鏈接池參數(shù)：

• MaxTotal：控制一個(gè)pool可分配多少個(gè)jedis實(shí)例，通過pool.getResource()來獲??；如果賦值為-1，則表示不限制；如果pool已經(jīng)分配了MaxTotal個(gè)jedis實(shí)例，則此時(shí)pool的狀態(tài)為exhausted。
• maxIdle：控制一個(gè)pool最多有多少個(gè)狀態(tài)為idle(空閑)的jedis實(shí)例；
• MaxWaitMillis：表示當(dāng)borrow一個(gè)jedis實(shí)例時(shí)，最大的等待毫秒數(shù)，如果超過等待時(shí)間，則直接拋JedisConnectionException；
• testOnBorrow：獲得一個(gè)jedis實(shí)例的時(shí)候是否檢查連接可用性（ping()）；如果為true，則得到的jedis實(shí)例均是可用的；

超賣

1.秒殺超賣現(xiàn)象

在高并發(fā)場景下，多個(gè)線程并發(fā)更新庫存，導(dǎo)致庫存為負(fù)的情況。

看圖幻想：

2.解決方案

（1）利用樂觀鎖淘汰用戶，解決超賣問題

上圖：

//增加樂觀鎖
jedis.watch(qtkey);
 
//3.判斷庫存
String qtkeystr = jedis.get(qtkey);
if(qtkeystr==null || "".equals(qtkeystr.trim())) {
	System.out.println("未初始化庫存");
	jedis.close();
	return false ;
}
 
int qt = Integer.parseInt(qtkeystr);
if(qt<=0) {
	System.err.println("已經(jīng)秒光");
	jedis.close();
	return false;
}
 
//增加事務(wù)
Transaction multi = jedis.multi();
 
//4.減少庫存
//jedis.decr(qtkey);
multi.decr(qtkey);
 
//5.加人
//jedis.sadd(usrkey, uid);
multi.sadd(usrkey, uid);
 
//執(zhí)行事務(wù)
List<Object> list = multi.exec();
 
//判斷事務(wù)提交是否失敗
if(list==null || list.size()==0) {
	System.out.println("秒殺失敗");
	jedis.close();
	return false;
}
System.err.println("秒殺成功");
jedis.close();	

方案原理：

（1）當(dāng)用戶購買時(shí)，通過watch來監(jiān)視庫存，如果庫存在watch監(jiān)視后發(fā)生改變，就會捕獲異常而放棄對庫存進(jìn)行減一操作。
（2）如果庫存沒有監(jiān)視到變化并且數(shù)量大于一時(shí)，則庫存減一，并且執(zhí)行任務(wù)。
弊端

Redis 在嘗試完成一個(gè)事務(wù)的時(shí)候，可能會因?yàn)槭聞?wù)的失敗而重復(fù)嘗試重新執(zhí)行
保證商品的庫存量正確是一件很重要的事情，但是單純的使用 WATCH 這樣的機(jī)制對服務(wù)器壓力過大

（2）、使用reids的 watch + multi + setnx 指令實(shí)現(xiàn)

為什么要自己構(gòu)建鎖？

雖然有類似的 SETNX 命令可以實(shí)現(xiàn) Redis 中的鎖的功能，但他鎖提供的機(jī)制并不完整
并且setnx也不具備分布式鎖的一些高級特性，還是得通過我們手動構(gòu)建。

（1）創(chuàng)建一個(gè)redis鎖

在 Redis 中，可以通過使用 SETNX 命令來構(gòu)建鎖：rs.setnx(lock_name, uuid值)
而鎖要做的事情就是將一個(gè)隨機(jī)生成的 128 位 UUID 設(shè)置位鍵的值，防止該鎖被其他進(jìn)程獲取。

（2）釋放鎖

鎖的刪除操作很簡單，只需要將對應(yīng)鎖的 key 值獲取到的 uuid 結(jié)果進(jìn)行判斷驗(yàn)證
符合條件（判斷uuid值）通過 delete 在 redis 中刪除即可，rs.delete(lockname)
此外當(dāng)其他用戶持有同名鎖時(shí)，由于 uuid 的不同，經(jīng)過驗(yàn)證后不會錯誤釋放掉別人的鎖.

（3）解決鎖無法釋放問題

在之前的鎖中，還出現(xiàn)這樣的問題，比如某個(gè)進(jìn)程持有鎖之后突然程序崩潰，那么會導(dǎo)致鎖無法釋放
而其他進(jìn)程無法持有鎖繼續(xù)工作，為了解決這樣的問題，可以在獲取鎖的時(shí)候加上鎖的超時(shí)功能。

到此這篇關(guān)于Redis中秒殺場景下超時(shí)與超賣問題的解決方案的文章就介紹到這了,更多相關(guān)Redis 超時(shí)與超賣內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論