Redis分布式鎖解決超賣問題的使用示例
前言
超賣問題通常出現在多用戶并發(fā)操作的情況下,即多個用戶嘗試購買同一件商品,導致商品庫存不足或者超賣。解決超賣問題的方法有很多:樂觀鎖、Redis分布式鎖、消息隊列等。分布式鎖是一種多節(jié)點共享的同步機制,通過在多個節(jié)點之間協(xié)調訪問資源,確保在同一時間只有一個節(jié)點能夠獲取鎖并執(zhí)行關鍵操作。在電商網站中,可以將每個商品的庫存作為共享資源,使用分布式鎖來控制并發(fā)訪問。
分布式鎖的目的是保證在分布式部署的應用集群中,多個服務在請求同一個方法或者同一個業(yè)務操作的情況下,對應業(yè)務邏輯只能被一臺機器上的一個線程執(zhí)行,避免出現并發(fā)問題。
分布式鎖要滿足的條件:
- 多進程互斥:同一時刻,只有一個進程可以獲取鎖
● 阻塞鎖(可選):獲取鎖失敗時可否重試
重入鎖(可選):獲取鎖的代碼遞歸調用時,依然可以獲取鎖 - 保證鎖可以釋放:任務結束或出現異常,鎖一定要釋放,避免死鎖
Redis分布式鎖:
在實現Redis分布式鎖之前,我們先來看看為什么Redis能實現分布式鎖:
在Redis中,利用Redis的setnx命令,這個命令的特征時如果多次執(zhí)行,只有第一次執(zhí)行會成功,可以實現互斥的效果。這滿足了多線程互斥的要求。
SETNX lock thread1
在Redis中,利用Redis的del命令,可以刪除一個key,即釋放鎖。
DEL lock
如果獲取鎖成功后服務宕機,發(fā)生了不釋放鎖的問題,Redis也可以通過給Key加有效時間,讓超時自動釋放。這樣一來,也滿足了保證鎖可以釋放,達到了分布式鎖必須滿足的條件!
EXPIRE lock 10
并且,也不用擔心在EXPIRE設置有效期之前服務宕機,Redis的set命令可以滿足setnx和expirr的原子性,用一個指令完成兩個步驟!
set lock thread1 EX 10 NX
分布式架構中實現
加Redis坐標
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>
配置Redis端口信息
Spring: redis: port: 6379 host: localhost
構造加鎖工具類
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è)務代碼上加鎖、解鎖
@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網關同意了API接口,由網關分發(fā)路由請求,通過OpenFegin實現通信并做到負載均衡效果,并對秒殺服務做了節(jié)點擴展,盡可能的模擬除了分布式架構:網關配置:
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
先測試不加分布式鎖的效果:數據庫庫存:10
秒殺記錄:0
運行服務:
JMeter測試數據:每秒500個請求
JMeter端口信息:
測試結果:
庫存還剩6個,消耗4個。
秒殺記錄已經一片糊涂了:
加上分布式鎖測試:測試數據如上。庫存為0:
秒殺記錄:
節(jié)點拓展后的三個秒殺服務:
三個服務都共同通過負載均衡消費了請求!
但還要注意的一點是,對于鎖的把控一定要按時釋放,一次的不釋放,可能都會導致后續(xù)請求無法成功!
到此這篇關于Redis分布式鎖解決超賣問題的使用示例的文章就介紹到這了,更多相關Redis 超賣內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
redis的hGetAll函數的性能問題(記Redis那坑人的HGETALL)
這篇文章主要介紹了redis的hGetAll函數的性能問題,需要的朋友可以參考下2016-02-02