前言
前面几篇博客，讲明了Redis的安装、配置和基本命令使用；以及java使用Redis操作数据、Springboot整合Redis操作数据等。
本篇博客以某公众号思想为例，写结合Redis对高并发环境下，商品超卖问题的解决思路。
超卖简单代码
写一段简单正常的超卖逻辑代码，多个微服务同时操作同一段数据，探究出现的问题。
Redis中存储一项数据信息，请求对应接口，获取商品数量信息；
商品数量信息如果大于0，则扣减1，重新存储Redis中；
运行代码测试问题。
其他代码的配置项，采取上一篇博客的配置为例：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* Redis数据库操作，超卖问题模拟
* @author
*
*/
@RestController
public class RedisController {
// 引入String类型redis操作模板
@Autowired
private StringRedisTemplate stringRedisTemplate;
// 测试数据设置接口
@RequestMapping("/setStock")
public String setStock() {
stringRedisTemplate.opsForValue().set("stock", 200+"");
return "ok";
}
// 模拟商品超卖代码
@RequestMapping("/deductStock")
public String deductStock() {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if(stock > 0) {
int realStock = stock -1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品："+realStock);
}else {
System.out.println("库存不足.....");
}
return "end";
}
}超卖问题
单服务器单应用情况下
在单应用模式下，使用
jmeter压测。
设置线程组
增加请求：
测试结果：
每个请求相当于一个线程，当几个线程同时拿到数据时，做了变更，但最先处理的数据，由于某些原因(延迟等)，造成数据最后的更新，覆盖了之前的卖出数据。导致超卖
既然线程和线程之间，数据处理不一致，能否使用synchronized加锁测试？
设置synchronized
依旧还是先测试单服务器上单微服务。
修改代码，增加synchronized：
@RequestMapping("/setStock")
public String setStock(String val) {
stringRedisTemplate.opsForValue().set("stock", val);
return "ok";
}
/**
* 模拟商品超卖代码 设置
* @return
*/
@RequestMapping("/deductStock2")
public String deductStock2() {
synchronized (this) {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if(stock > 0) {
int realStock = stock -1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品："+realStock);
}else {
System.out.println("库存不足.....");
}
}
return "end";
}这次商品数量设置100，
http://localhost/setStock?val=100
重新压测：
此时压测，得到的日志信息如下所示：
在单机模式下，添加synchronized关键字，的确能够避免商品的超卖现象！
但是在分布式微服务中，针对该服务，如果设置了集群，synchronized依旧还能保证数据的正确性吗？
假设多个请求，被注册中心负载均衡，每个微服务中的该处理接口，都添加有synchronized，
依然会出现类似的超卖问题：
synchronized只是针对单一服务器的JVM进行加锁，但是分布式是很多个不同的服务器，导致两个线程或多个在不同服务器上共同对商品数量信息做了操作！
Redis实现分布式锁
在Redis中存在一条命令setnx (set if not exists)
setnx key value
如果不存在key，则可以设置成功；否则设置失败。
修改处理接口，增加key
/**
* 模拟商品超卖代码 设置
*
* @return
*/
@RequestMapping("/deductStock3")
public String deductStock3() {
// 创建一个key，保存至redis
String key = "lock";
// setnx
// 由于redis是一个单线程，执行命令采取“队列”形式排队！
// 优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败。
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
if (!result) {
// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
return "err";
}
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if (stock > 0) {
int realStock = stock - 1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品：" + realStock);
} else {
System.out.println("库存不足.....");
}
// 程序执行完成，则删除这个key
stringRedisTemplate.delete(key);
return "end";
}1、请求进入接口中，如果redis中不存在key，则会新建一个setnx；如果存在，则不会新建，同时返回错误编码，不会继续执行抢购逻辑。
2、当创建成功后，执行抢购逻辑。
3、抢购逻辑执行完成后，删除数据库中对应的setnx的key。让其他请求能够设置并操作。
这种逻辑来说比之前单一使用syn合理的多，但是如果执行抢购操作中出现了异常，导致这个key无法被删除。以至于其他处理请求，一直无法拿到key，程序逻辑死锁！
try…finally解决Redis分布式锁问题
如何解决上述的死锁问题？
可以采取try … finally进行操作
修改业务代码逻辑，如下所示：
/**
* 模拟商品超卖代码 设置
*
* @return
*/
@RequestMapping("/deductStock4")
public String deductStock4() {
// 创建一个key，保存至redis
String key = "lock";
// setnx
// 由于redis是一个单线程，执行命令采取队列形式排队！优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
if (!result) {
// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
return "err";
}
try {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if (stock > 0) {
int realStock = stock - 1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品：" + realStock);
} else {
System.out.println("库存不足.....");
}
} finally {
// 程序执行完成，则删除这个key
// 放置于finally中，保证即使上述逻辑出问题，也能del掉
stringRedisTemplate.delete(key);
}
return "end";
}这个逻辑相比上面其他的逻辑来说，显得更加的严谨。
但是，如果一套服务器，因为断电、系统崩溃等原因出现宕机，导致本该执行finally中的语句未成功执行完成！！同样出现key一直存在，导致死锁！
通过超时间解决上述问题
在设置成功setnx后，以及抢购代码逻辑执行前，增加key的限时。
/**
* 模拟商品超卖代码 设置setnx保证分布式环境下，数据处理安全行问题；<br>
* 但如果某个代码段执行异常，导致key无法清理，出现死锁，添加try...finally;<br>
* 如果某个服务因某些问题导致释放key不能执行，导致死锁，此时解决思路为：增加key的有效时间
*
* @return
*/
@RequestMapping("/deductStock5")
public String deductStock5() {
// 创建一个key，保存至redis
String key = "lock";
// setnx
// 由于redis是一个单线程，执行命令采取队列形式排队！优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
if (!result) {
// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
return "err";
}
// 设置key有效时间
stringRedisTemplate.expire(key, 10, TimeUnit.SECONDS);
try {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if (stock > 0) {
int realStock = stock - 1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品：" + realStock);
} else {
System.out.println("库存不足.....");
}
} finally {
// 程序执行完成，则删除这个key
// 放置于finally中，保证即使上述逻辑出问题，也能del掉
stringRedisTemplate.delete(key);
}
return "end";
}但是在上面的代码中，依旧会出现问题：
假设执行
stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");代码逻辑后，因为服务器原因，服务器宕机。
导致下列设置的key有效时间代码逻辑未执行。依旧会出现之前说的死锁问题。
能否保证设置key和设置时间代码能同时执行？
在Redis中，开发者考虑到这种情况，新增了一项方法可以使用，如下所示：
/**
* 模拟商品超卖代码 设置setnx保证分布式环境下，数据处理安全行问题；<br>
* 但如果某个代码段执行异常，导致key无法清理，出现死锁，添加try...finally;<br>
* 如果某个服务因某些问题导致释放key不能执行，导致死锁，此时解决思路为：增加key的有效时间;<br>
* 为了保证设置key的值和设置key的有效时间，两条命令构成同一条原子命令，将下列逻辑换成其他代码。
*
* @return
*/
@RequestMapping("/deductStock6")
public String deductStock6() {
// 创建一个key，保存至redis
String key = "lock";
// setnx
// 由于redis是一个单线程，执行命令采取队列形式排队！优先进入队列的命令先执行，由于是setnx，第一个执行后，其他操作执行失败
//boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock");
//让设置key和设置key的有效时间都可以同时执行
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, "this is lock", 10, TimeUnit.SECONDS);
// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
if (!result) {
// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
return "err";
}
// 设置key有效时间
//stringRedisTemplate.expire(key, 10, TimeUnit.SECONDS);
try {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if (stock > 0) {
int realStock = stock - 1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品：" + realStock);
} else {
System.out.println("库存不足.....");
}
} finally {
// 程序执行完成，则删除这个key
// 放置于finally中，保证即使上述逻辑出问题，也能del掉
stringRedisTemplate.delete(key);
}
return "end";
}//让设置key和设置key的有效时间都可以同时执行
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, “this is lock”, 10, TimeUnit.SECONDS);
将setIfAbsent和expire两条命令合并成一条原子命令。
但是上述代码的逻辑中依旧会有问题：
如果处理逻辑中，出现
超时问题。
当逻辑执行时，时间超过设定key有效时间，此时会出现什么问题？
从上图可以清楚的发现问题：
如果一个请求执行时间超过了key的有效时间。
新的请求执行过来时，必然可以拿到key并设置时间；
此时的redis中保存的key并不是请求1的key，而是别的请求设置的。
当请求1执行完成后，此处删除key，删除的是别的请求设置的key！
依然出现了key形同虚设的问题！如果失效一直存在，超卖问题依旧不会解决。
通过key设置值匹配的方式解决形同虚设问题
既然出现key形同虚设的现象，是否可以增加条件，当finally中需要执行删除操作时，获取数据判断值是否是该请求中对应的，如果是则删除，不是则不管！
修改上述代码如下所示：
/**
* 模拟商品超卖代码 <br>
* 解决`deductStock6`中，key形同虚设的问题。
*
* @return
*/
@RequestMapping("/deductStock7")
public String deductStock7() {
// 创建一个key，保存至redis
String key = "lock";
String lock_value = UUID.randomUUID().toString();
// setnx
//让设置key和设置key的有效时间都可以同时执行
boolean result = stringRedisTemplate.opsForValue().setIfAbsent(key, lock_value, 10, TimeUnit.SECONDS);
// 当不存在key时，可以设置成功，回执true；如果存在key，则无法设置，返回false
if (!result) {
// 前端监测，redis中存在，则不能让这个抢购操作执行，予以提示！
return "err";
}
try {
// 获取Redis数据库中的商品数量
Integer stock = Integer.parseInt(stringRedisTemplate.opsForValue().get("stock"));
// 减库存
if (stock > 0) {
int realStock = stock - 1;
stringRedisTemplate.opsForValue().set("stock", String.valueOf(realStock));
System.out.println("商品扣减成功，剩余商品：" + realStock);
} else {
System.out.println("库存不足.....");
}
} finally {
// 程序执行完成，则删除这个key
// 放置于finally中，保证即使上述逻辑出问题，也能del掉
// 判断redis中该数据是否是这个接口处理时的设置的，如果是则删除
if(lock_value.equalsIgnoreCase(stringRedisTemplate.opsForValue().get(key))) {
stringRedisTemplate.delete(key);
}
}
return "end";
}但是此处也有一个很极限的问题：
1、在finally流程中，由于是先判断在处理。
2、如果判断条件结束后，获取到的结果为true。
3、但是在执行del操作前，此时jvm在执行GC操作(为了保证GC操作获取GC roots根完全，会暂停java程序)，导致程序暂停。
4、GC操作执行完成后(暂停恢复后)，执行del操作，但是此时的key还在当前加锁的key么？
总结：
必须保证del操作的判断和执行能够同时执行，此处代码才合理。
