某东新发一块新机,每人限购2台,预计会有10W的并发,在该情况下,如果扣减库存,保证不会超卖
解决方案一
利用数据库锁机制,对记录进行锁定,再进行操作
SELECT * from goods where ID =1 for update;
UPDATE goods set stock = stock - 1;
解决方案二
使用时间戳字段实现数据更新,避免强制性的数据独占
比如goods表新增一个 version字段
select * from goods where ID=1
update goods set stock = stock -1,version=now where ID =1 and version = ?
利用排它锁将并行转化为串行操作,但该方案的性能和用户体验较差
解决方案二
利用redis 实现分布式锁,
使用setnx命令(在key不存在时,创建并设置value 返回1,key存在时,会反回0)来获取锁,在业务逻辑中,我们可以通过这样的方案来操作。
技术背景引入:
Jedis client = jedisPool.getResource();
while(client.setnx("lock",String.valueOf(System.currentTimeMillis())) == 0){
//加锁成功:加锁该记录,此处如果一直存在,表名需要进行等待;
Thread.sleep(10000);
}
//加锁失败:执行循环外的代码。
//coding here
//整体业务执行完成,删除锁定的锁
client.del("lock")
方案二进阶
考虑到死锁问题,即现成A获取锁后,宕机了,导致锁一直无法释放,我们可以通过get命令获取锁的时间戳,通过他进行超时判断,并进行释放。此方案在方案二的基础上增强了时间的计算,避免了线程独占,及时的进行删除锁。
Long TIMEOUT_SECOUND = 80000L;
Jedis client = jedisPool.getResource();
while(client.setnx("lock",String.valueOf(System.currentTimeMillis())) == 0){
Long lockTime = Long.valueOf(client.get("lock"));
if (lockTime!=null && System.currentTimeMillis() > lockTime+TIMEOUT_SECOUND) {
client.del("lock");
}
Thread.sleep(10000);
}
...........................
...........................
client.del("lock")
方案二加强
方案2的算法中,为了确保在非超时情况下,锁只能由有锁的线程进行释放,可以在value的时间戳中,拼上线程特征码=(产品ID)。适用场景:商城中对多个商品的更新操作,根据商品ID和时间进行加锁
Long TIMEOUT_SECOUND = 80000L;
String productId= "ATX-001";
Jedis client = jedisPool.getResource();
while(client.setnx("lock",productId+":"+String.valueOf(System.currentTimeMillis())) == 0){
Long lockTime = Long.valueOf(client.get("lock").substring(9));
if (lockTime!=null && System.currentTimeMillis() > lockTime+TIMEOUT_SECOUND) {
client.del("lock");
}
Thread.sleep(10000);
}
...........................
...........................
if (productId.equals(client.get("lock").substring(0, 8))) {
client.del("lock");
}