Redis分布式鎖解決超賣問題的使用示例
前言
超賣問題通常出現(xiàn)在多用戶并發(fā)操作的情況下,即多個用戶嘗試購買同一件商品,導(dǎo)致商品庫存不足或者超賣。解決超賣問題的方法有很多:樂觀鎖、Redis分布式鎖、消息隊列等。分布式鎖是一種多節(jié)點(diǎn)共享的同步機(jī)制,通過在多個節(jié)點(diǎn)之間協(xié)調(diào)訪問資源,確保在同一時間只有一個節(jié)點(diǎn)能夠獲取鎖并執(zhí)行關(guān)鍵操作。在電商網(wǎng)站中,可以將每個商品的庫存作為共享資源,使用分布式鎖來控制并發(fā)訪問。

分布式鎖的目的是保證在分布式部署的應(yīng)用集群中,多個服務(wù)在請求同一個方法或者同一個業(yè)務(wù)操作的情況下,對應(yīng)業(yè)務(wù)邏輯只能被一臺機(jī)器上的一個線程執(zhí)行,避免出現(xiàn)并發(fā)問題。
分布式鎖要滿足的條件:
- 多進(jìn)程互斥:同一時刻,只有一個進(jìn)程可以獲取鎖
● 阻塞鎖(可選):獲取鎖失敗時可否重試
重入鎖(可選):獲取鎖的代碼遞歸調(diào)用時,依然可以獲取鎖 - 保證鎖可以釋放:任務(wù)結(jié)束或出現(xiàn)異常,鎖一定要釋放,避免死鎖
Redis分布式鎖:
在實現(xiàn)Redis分布式鎖之前,我們先來看看為什么Redis能實現(xiàn)分布式鎖:
在Redis中,利用Redis的setnx命令,這個命令的特征時如果多次執(zhí)行,只有第一次執(zhí)行會成功,可以實現(xiàn)互斥的效果。這滿足了多線程互斥的要求。
SETNX lock thread1
在Redis中,利用Redis的del命令,可以刪除一個key,即釋放鎖。
DEL lock
如果獲取鎖成功后服務(wù)宕機(jī),發(fā)生了不釋放鎖的問題,Redis也可以通過給Key加有效時間,讓超時自動釋放。這樣一來,也滿足了保證鎖可以釋放,達(dá)到了分布式鎖必須滿足的條件!
EXPIRE lock 10
并且,也不用擔(dān)心在EXPIRE設(shè)置有效期之前服務(wù)宕機(jī),Redis的set命令可以滿足setnx和expirr的原子性,用一個指令完成兩個步驟!
set lock thread1 EX 10 NX
分布式架構(gòu)中實現(xiàn)
加Redis坐標(biāo)
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>
配置Redis端口信息
Spring: redis: port: 6379 host: localhost
構(gòu)造加鎖工具類
public interface ILock {
/**
* 嘗試獲取鎖
* @param timeoutSec 鎖持有的超時時間,過期后自動釋放
* @return true代表獲取鎖成功; false代表獲取鎖失敗
*/
boolean tryLock(long timeoutSec);
/**
* 釋放鎖
*/
void unlock();
}public class SimpleRedisLock implements ILock {
private StringRedisTemplate stringRedisTemplate;
public SimpleRedisLock(StringRedisTemplate stringRedisTemplate) {
this.stringRedisTemplate = stringRedisTemplate;
}
@Override
public boolean tryLock(long timeoutSec) {
Boolean secuss = stringRedisTemplate.opsForValue()
.setIfAbsent("lock", "thread", timeoutSec, TimeUnit.SECONDS);
return secuss;
}
@Override
public void unlock() {
stringRedisTemplate.delete("lock");
}
}在實際秒殺業(yè)務(wù)代碼上加鎖、解鎖
@PostMapping("/kill")
public String executeSeckillProduct(int productId,int seckillCount){
//獲取鎖對象
SimpleRedisLock redisLock =new SimpleRedisLock(stringRedisTemplate);
//嘗試獲取鎖對象
boolean isLock = redisLock.tryLock(1200);
if(!isLock){
return "獲取鎖失敗";
}
Product product = productService.findByPid(productId);
if(product.getStock()<seckillCount){
return "庫存不足";
}
product.setStock(product.getStock()-seckillCount);
int row = productService.reduceInventory(product);
if(row>0){
//新增秒殺記錄
SeckillRecord record = new SeckillRecord();
record.setPid(product.getPid());
record.setCount(seckillCount);
record.setPanme(product.getPname());
record.setTime(new Timestamp(System.currentTimeMillis()));
recodeService.save(record);
}
//釋放鎖
redisLock.unlock();
return "秒殺成功";
}測試
在測試Redis分布式鎖之前,我先用了GetWay網(wǎng)關(guān)同意了API接口,由網(wǎng)關(guān)分發(fā)路由請求,通過OpenFegin實現(xiàn)通信并做到負(fù)載均衡效果,并對秒殺服務(wù)做了節(jié)點(diǎn)擴(kuò)展,盡可能的模擬除了分布式架構(gòu):網(wǎng)關(guān)配置:
server:
port: 7000
spring:
application:
name: gateway-application
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
gateway:
discovery:
locator:
enabled: true
routes:
- id: reckill_route
uri: lb://service-reckill
order: 1
predicates:
- Path=/reckill-serv/**
filters:
- StripPrefix=1先測試不加分布式鎖的效果:數(shù)據(jù)庫庫存:10

秒殺記錄:0

運(yùn)行服務(wù):

JMeter測試數(shù)據(jù):每秒500個請求

JMeter端口信息:

測試結(jié)果:
庫存還剩6個,消耗4個。

秒殺記錄已經(jīng)一片糊涂了:

加上分布式鎖測試:測試數(shù)據(jù)如上。庫存為0:

秒殺記錄:

節(jié)點(diǎn)拓展后的三個秒殺服務(wù):



三個服務(wù)都共同通過負(fù)載均衡消費(fèi)了請求!
但還要注意的一點(diǎn)是,對于鎖的把控一定要按時釋放,一次的不釋放,可能都會導(dǎo)致后續(xù)請求無法成功!
到此這篇關(guān)于Redis分布式鎖解決超賣問題的使用示例的文章就介紹到這了,更多相關(guān)Redis 超賣內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
使用Redis實現(xiàn)數(shù)據(jù)庫對象自增ID的方法
在分布式項目中,數(shù)據(jù)表的主鍵ID一般可能存在于UUID或自增ID這兩種形式,UUID好理解而且實現(xiàn)起來也最容易,但是缺點(diǎn)就是數(shù)據(jù)表中的主鍵ID是32位的字符串,我們通常會優(yōu)先考慮使用自增ID來代替UUID使用,所以本文介紹了使用Redis實現(xiàn)生成對象自增ID的方法2024-11-11
redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)
這篇文章主要介紹了redis的hGetAll函數(shù)的性能問題,需要的朋友可以參考下2016-02-02
nestjs使用redis實現(xiàn)ip限流的步驟詳解
如果使用nestjs開發(fā)接口并部署之后,我們通常需要考慮到接口是否會被惡意盜刷消耗過多的資源,一個簡單的方式就是限制在單位時間內(nèi)的訪問次數(shù),所以本文給大家介紹了nestjs使用redis實現(xiàn)ip限流的步驟,需要的朋友可以參考下2025-01-01

