Redis分布式鎖解決超賣問題的使用示例
前言
超賣問題通常出現(xiàn)在多用戶并發(fā)操作的情況下,即多個(gè)用戶嘗試購買同一件商品,導(dǎo)致商品庫存不足或者超賣。解決超賣問題的方法有很多:樂觀鎖、Redis分布式鎖、消息隊(duì)列等。分布式鎖是一種多節(jié)點(diǎn)共享的同步機(jī)制,通過在多個(gè)節(jié)點(diǎn)之間協(xié)調(diào)訪問資源,確保在同一時(shí)間只有一個(gè)節(jié)點(diǎn)能夠獲取鎖并執(zhí)行關(guān)鍵操作。在電商網(wǎng)站中,可以將每個(gè)商品的庫存作為共享資源,使用分布式鎖來控制并發(fā)訪問。
分布式鎖的目的是保證在分布式部署的應(yīng)用集群中,多個(gè)服務(wù)在請求同一個(gè)方法或者同一個(gè)業(yè)務(wù)操作的情況下,對應(yīng)業(yè)務(wù)邏輯只能被一臺機(jī)器上的一個(gè)線程執(zhí)行,避免出現(xiàn)并發(fā)問題。
分布式鎖要滿足的條件:
- 多進(jìn)程互斥:同一時(shí)刻,只有一個(gè)進(jìn)程可以獲取鎖
● 阻塞鎖(可選):獲取鎖失敗時(shí)可否重試
重入鎖(可選):獲取鎖的代碼遞歸調(diào)用時(shí),依然可以獲取鎖 - 保證鎖可以釋放:任務(wù)結(jié)束或出現(xiàn)異常,鎖一定要釋放,避免死鎖
Redis分布式鎖:
在實(shí)現(xiàn)Redis分布式鎖之前,我們先來看看為什么Redis能實(shí)現(xiàn)分布式鎖:
在Redis中,利用Redis的setnx命令,這個(gè)命令的特征時(shí)如果多次執(zhí)行,只有第一次執(zhí)行會成功,可以實(shí)現(xiàn)互斥的效果。這滿足了多線程互斥的要求。
SETNX lock thread1
在Redis中,利用Redis的del命令,可以刪除一個(gè)key,即釋放鎖。
DEL lock
如果獲取鎖成功后服務(wù)宕機(jī),發(fā)生了不釋放鎖的問題,Redis也可以通過給Key加有效時(shí)間,讓超時(shí)自動釋放。這樣一來,也滿足了保證鎖可以釋放,達(dá)到了分布式鎖必須滿足的條件!
EXPIRE lock 10
并且,也不用擔(dān)心在EXPIRE設(shè)置有效期之前服務(wù)宕機(jī),Redis的set命令可以滿足setnx和expirr的原子性,用一個(gè)指令完成兩個(gè)步驟!
set lock thread1 EX 10 NX
分布式架構(gòu)中實(shí)現(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 鎖持有的超時(shí)時(shí)間,過期后自動釋放 * @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"); } }
在實(shí)際秒殺業(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實(shí)現(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個(gè)請求
JMeter端口信息:
測試結(jié)果:
庫存還剩6個(gè),消耗4個(gè)。
秒殺記錄已經(jīng)一片糊涂了:
加上分布式鎖測試:測試數(shù)據(jù)如上。庫存為0:
秒殺記錄:
節(jié)點(diǎn)拓展后的三個(gè)秒殺服務(wù):
三個(gè)服務(wù)都共同通過負(fù)載均衡消費(fèi)了請求!
但還要注意的一點(diǎn)是,對于鎖的把控一定要按時(shí)釋放,一次的不釋放,可能都會導(dǎo)致后續(xù)請求無法成功!
到此這篇關(guān)于Redis分布式鎖解決超賣問題的使用示例的文章就介紹到這了,更多相關(guān)Redis 超賣內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
使用Redis實(shí)現(xiàn)數(shù)據(jù)庫對象自增ID的方法
在分布式項(xiàng)目中,數(shù)據(jù)表的主鍵ID一般可能存在于UUID或自增ID這兩種形式,UUID好理解而且實(shí)現(xiàn)起來也最容易,但是缺點(diǎn)就是數(shù)據(jù)表中的主鍵ID是32位的字符串,我們通常會優(yōu)先考慮使用自增ID來代替UUID使用,所以本文介紹了使用Redis實(shí)現(xiàn)生成對象自增ID的方法2024-11-11RedisTemplate的使用與注意事項(xiàng)小結(jié)
本文詳細(xì)介紹了RedisTemplate的用途和使用方法,RedisTemplate是Spring提供的一個(gè)工具類,用于操作Redis數(shù)據(jù)庫,其API提供了豐富的方法來實(shí)現(xiàn)對Redis各種操作,本文就來詳細(xì)的介紹一下,感興趣的可以來了解一下2024-10-10redis的hGetAll函數(shù)的性能問題(記Redis那坑人的HGETALL)
這篇文章主要介紹了redis的hGetAll函數(shù)的性能問題,需要的朋友可以參考下2016-02-02Redis實(shí)現(xiàn)訂單自動過期功能的示例代碼
這篇文章主要介紹了Redis實(shí)現(xiàn)訂單自動過期功能的示例代碼,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-05-05Redis延遲隊(duì)列和分布式延遲隊(duì)列的簡答實(shí)現(xiàn)
在我們的工作中,很多地方使用延遲隊(duì)列,比如訂單到期沒有付款取消訂單,制訂一個(gè)提醒的任務(wù)等都需要延遲隊(duì)列,那么我們需要實(shí)現(xiàn)延遲隊(duì)列,本文就來介紹一下如何實(shí)現(xiàn),感興趣的可以了解一下2021-05-05nestjs使用redis實(shí)現(xiàn)ip限流的步驟詳解
如果使用nestjs開發(fā)接口并部署之后,我們通常需要考慮到接口是否會被惡意盜刷消耗過多的資源,一個(gè)簡單的方式就是限制在單位時(shí)間內(nèi)的訪問次數(shù),所以本文給大家介紹了nestjs使用redis實(shí)現(xiàn)ip限流的步驟,需要的朋友可以參考下2025-01-01