一:全局唯一ID
1.场景:
方便数据的统计和保证数据的真实性质,一般来说常用于电商系统,如订单模块;一般要满足唯一性,高性能,高可用,单调递增,安全性;
2.问题:
- 为什么不使用自增序列?
- id 规律太明显,容易被猜出一些信息;
- 受到单表数据量的限制;
3.设置:
1.实现思想
使用redis来完成,为了增加ID的安全性,不可以使用redis的自增的数值,而是拼接一些其他信息;
可以设置64位 ID组成:
符号位 1bit,永远为0;
时间戳 31bit,可以使用69年;
序列号 32bit,支持每秒产生2的32个不同ID;
2.代码
package com.***.flow.utils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;
import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.time.format.DateTimeFormatter;
@Component
public class IdWorker {
//开始时间戳
@Autowired
private StringRedisTemplate stringRedisTemplate;
private static final long beginTime = 1640995200L;
public long nextId(String prefix) {
//1.生成时间戳
LocalDateTime now = LocalDateTime.now();
long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
long timestamp = nowSecond - beginTime;
//2.生成序列号
//2.1获取当前时间,精确到天
String date = now.format(DateTimeFormatter.ofPattern("yyyyMMdd"));
long count = stringRedisTemplate.opsForValue().increment("icr:" + prefix + ":" + date);
//3.拼接并返回
//高位运算 或运算
return timestamp << 32 | count;
}
public static void main(String[] args) {
//时间戳
LocalDateTime time = LocalDateTime.of(2022, 1, 1, 0, 0);
long second = time.toEpochSecond(ZoneOffset.UTC);
System.out.println(second);
//1640995200L
}
}
3.补充
- 其他生成策略:UUID,雪花算法;
- redis自增策略:每天一个key,方便进行数据的统计;
二:实现秒杀下单
1.场景:
电商平台通过优惠卷做活动,容易产生秒杀问题.即高并发下如何维持数据的一致性;
2.分析:
涉及表会有商铺表,优惠卷表,秒杀优惠卷表,订单表;秒杀优惠卷id属于优惠卷id,存在着开始时间和结束时间;在秒杀情况下,就需要判断是否在秒杀时间内,判断库存是否充足;
3.逻辑:
- 通过id查询db 是否存在秒杀优惠卷?
- T 存在,判断是否在优惠期内?
- T:判断是否存在库存?
- T:扣减库存,生成订单,return success;
- F:return errorMsg;
- F:return errorMsg;
- T:判断是否存在库存?
- F 不存在 return errorMsg;
- T 存在,判断是否在优惠期内?
4.伪代码:
public Result orderBy(String id) {
Vouchers vouchers = getById(id);
if (vouchers == null) {
return Result.fail("不存在该数据");
}
//判断当前时间
Boolean flag = vouchers.getStart().isAfter(LocalDateTime.now())
|| vouchers.getEnd().isBefore(LocalDateTime.now());
if (flag){
return Result.fail("不在优惠卷使用时间内");
}
//判断是否有库存
if (vouchers.getCount()>0) {
vouchers.setCount(vouchers.getCount() - 1);
this.updateVoucher(vouchers);
Order order = new Order();
//订单信息
this.save(order);
return Result.ok(order.getId());
}
return Result.fail("没库存");
}
5.问题:
上面的代码中:
假设线程1过来查询库存，判断出来库存大于1，正准备去扣减库存，但是还没有来得及去扣减，此时线程2过来，线程2也去查询库存，发现这个数量一定也大于1，那么这两个线程都会去扣减库存，最终多个线程相当于一起去扣减库存，此时就会出现库存的超卖问题。
三:超卖问题
1.产生场景:
如上,这是一个典型的高并发下多线程安全问题，针对这一问题的常见解决方案就是加锁：而对于加锁，我们通常有两种解决方案：悲观锁,乐观锁
2.悲观锁与乐观锁
2.1 悲观锁思想：
悲观锁认为线程安全问题一定会发生,因此在数据操作前先获取锁,确保线程串行执行.
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
悲观锁sql
select * from tableName for update;
其他相关:Synchronized锁优化,lock锁机制原理;
2.2 乐观锁思想：
乐观锁认为线程安全问题不一定会发生,因此不加锁,只是在更新数据时判断有没有其他线程对数据做了修改：
- 如果没有修改则认为是安全的,自己才更新数据
- 如果数据已经被修改则说明发生了安全问题,此时可以重试或异常;
2.2.1 乐观锁实现:版本号
| id | count | version |
|---|---|---|
| 1 | 100 | 1 |
线程1:
- 1.查询数量和版本 count = 100,version = 1;
- 2.判断库存是否足够?足够扣减,否报错;
update tbleName set count = count - 1,version = version + 1 where id = 1 and version = 1;
线程2:
- 1.查询数量和版本 count = 100,version = 1;
- 2.判断库存是否足够?足够扣减,否报错;
## 这个时候 该sql就不执行,保证数据安全
update tbleName set count = count - 1,version = version + 1 where id = 1 and version = 1;
2.2.2 乐观锁实现:CAS
cas 的本质是对版本的简化,通过获取的值与 要改变的值是否一致来进行判断;
| id | count |
|---|---|
| 1 | 100 |
线程1:
- 1.查询数量 count = 100;
- 2.判断库存是否足够?足够扣减,否报错;
update tbleName set count = count - 1 where id = 1 and count = 100;
线程2:
- 1.查询数量 count = 100;
- 2.判断库存是否足够?足够扣减,否报错;
## 这个时候 该sql就不执行,保证数据安全
update tbleName set count = count - 1 where id = 1 and count = 100;
2.2.2.1 CAS算法理解
CAS算法（Compare And Swap），即比较并交换，是解决多线程并行情况下使用锁造成性能损耗的一种机制，CAS包含三个操作数更新的变量,预期原值,新值.核心算法是如果变量值等于预期值，则将变量值设为新值，若变量值和预期值不同，则说明已经有其他线程做了更新，当前线程则不做更新.
CAS和自旋
-
cas: 只是比较和交换,只是可以在cas的时候可以利用自旋机制不断进行重试;
-
自旋: 是一种锁优化机制,自旋锁(线程空转重试获取锁),自旋不一定要在cas场景,也可以用于互斥锁;
-
cas + 自旋: 会经常结合使用,用来实现线程安全,不使用锁的读写操作;
2.2.2.2 CAS算法存在的问题
2.2.2.2.1 ABA问题
ABA问题:因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B-3A。
2.2.2.2.2 循环时间长开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销;
2.2.2.2.3 只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。
2.3 两种锁的使用场景
- 乐观锁
- 适合读多写少的场景,这样可以节省锁的开销,加大系统的吞吐量.
- 写多的情况下,容易产生冲突,导致不断重试;反而浪费性能;
- 悲观锁
- 适合写多的情况,保证线程安全和数据安全;
2.4 乐观锁实现业务
/* 只要我扣减库存时的库存和之前我查询到的库存是一样的就意味着没有人在中间
修改过库存，那么此时就是安全的，但是以上这种方式通过 测试发现会有很多失败
的情况，失败的原因在于：在使用乐观锁过程中假设100个线程同时都拿到了100
的库存，然后大家一起去进行扣减，但是100个人中只有1个人能扣减成功，其他的
人在处理时，他们在扣减时，库存已经被修改过了，所以此时其他线程都会失败*/
update tbleName set count = count - 1,
version = version + 1 where id = 1 and version = 1;
//更加合适的sql
update tbleName set count = count - 1
where id = 1 and count > 0;
四:一人一单问题
1.场景
修改秒杀业务,要求同一个优惠卷,一个用户只能下一单;
2.初步代码
在秒杀的基础上增加一人一单的逻辑,实际上只要查询出数据库中存在该用户的优惠卷,就不添加订单即可;
public Result seckillVoucher(Long voucherId) {
// 1.查询优惠券
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
// 2.判断秒杀是否开始
if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀尚未开始！");
}
// 3.判断秒杀是否已经结束
if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀已经结束！");
}
// 4.判断库存是否充足
if (voucher.getStock() < 1) {
// 库存不足
return Result.fail("库存不足！");
}
// 5.一人一单逻辑
// 5.1.用户id
Long userId = UserHolder.getUser().getId();
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次！");
}
//6，扣减库存
boolean success = seckillVoucherService.update()
.setSql("stock= stock -1")
.eq("voucher_id", voucherId).update();
if (!success) {
//扣减库存
return Result.fail("库存不足！");
}
//7.创建订单
VoucherOrder voucherOrder = new VoucherOrder();
// 7.1.订单id
long orderId = redisIdWorker.nextId("order");
voucherOrder.setId(orderId);
voucherOrder.setUserId(userId);
// 7.3.代金券id
voucherOrder.setVoucherId(voucherId);
save(voucherOrder);
return Result.ok(orderId);
}
问题: 经过测试可以发现,在高并发下的基础下,依然是可以下多次单的;这是因为高并发的情况下,线程会交叉执行,在第一次查询时,有多个线程查询结果为不存在该用户信息.所以都会向下执行添加订单,从而产生多个订单;
3.代码改进
3.1 问题:并发后出现多个插入数据
3.1.1 方案
现在的问题还是和之前一样，并发过来，查询数据库，都不存在订单，所以我们还是需要加锁，但是乐观锁比较适合更新数据，而现在是插入数据，所以我们需要使用悲观锁操作;
在这里提到了非常多的问题，我们需要慢慢的来思考，首先我们的初始方案是封装了一个createVoucherOrder方法，同时为了确保他线程安全，在方法上添加了一把synchronized 锁
3.1.2 伪代码
@Transactional
public synchronized Result createVoucherOrder(Long voucherId) {
Long userId = UserHolder.getUser().getId();
// 5.1.查询订单
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次！");
}
// 6.扣减库存
boolean success = seckillVoucherService.update()
.setSql("stock = stock - 1") // set stock = stock - 1
.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
.update();
if (!success) {
// 扣减失败
return Result.fail("库存不足！");
}
// 7.创建订单
VoucherOrder voucherOrder = new VoucherOrder();
// 7.1.订单id
long orderId = redisIdWorker.nextId("order");
voucherOrder.setId(orderId);
// 7.2.用户id
voucherOrder.setUserId(userId);
// 7.3.代金券id
voucherOrder.setVoucherId(voucherId);
save(voucherOrder);
// 7.返回订单id
return Result.ok(orderId);
}
3.2 问题:锁粒度过粗
3.2.1 方案
但是这样添加锁，锁的粒度太粗了，在使用锁过程中，控制锁粒度 是一个非常重要的事情，因为如果锁的粒度太大，会导致每个线程进来都会锁住，所以我们需要去控制锁的粒度，以下这段代码需要修改为：
3.2.2 伪代码
@Transactional
public Result createVoucherOrder(Long voucherId) {
Long userId = UserHolder.getUser().getId();
synchronized(userId.toString().intern()){
// 5.1.查询订单
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次！");
}
// 6.扣减库存
boolean success = seckillVoucherService.update()
.setSql("stock = stock - 1") // set stock = stock - 1
.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
.update();
if (!success) {
// 扣减失败
return Result.fail("库存不足！");
}
// 7.创建订单
VoucherOrder voucherOrder = new VoucherOrder();
// 7.1.订单id
long orderId = redisIdWorker.nextId("order");
voucherOrder.setId(orderId);
// 7.2.用户id
voucherOrder.setUserId(userId);
// 7.3.代金券id
voucherOrder.setVoucherId(voucherId);
save(voucherOrder);
// 7.返回订单id
return Result.ok(orderId);
}
}
注意事项: intern() 这个方法是从常量池中拿到数据，如果我们直接使用userId.toString() 他拿到的对象实际上是不同的对象，new出来的对象，我们使用锁必须保证锁必须是同一把，所以我们需要使用intern()方法;
3.3 问题:锁释放时间
3.2.1 方案
以上代码还是存在问题，问题的原因在于当前方法被spring的事务控制，如果你在方法内部加锁，可能会导致当前方法事务还没有提交，但是锁已经释放也会导致问题，所以我们选择将当前方法整体包裹起来，确保事务不会出现问题：如下：
在seckillVoucher 方法中，添加以下逻辑，这样就能保证事务的特性，同时也控制了锁的粒度
3.2.2 伪代码
Long userId = UserHolder.getUser().getId();
synchronized (userId.toString().intern()) {
return this.createVoucherOrder(voucherId);
}
3.2.3 注意事项
但是以上做法依然有问题，因为你调用的方法，其实是this.的方式调用的，事务想要生效，还得利用代理来生效，所以这个地方，我们需要获得原始的事务对象， 来操作事务
Long userId = UserHolder.getUser().getId();
synchronized (userId.toString().intern()) {
LoginService proxy = (LoginService) AopContext.currentProxy();
return proxy.createVoucherOrder(voucherId);
}
//启动类需要添加
@EnableAspectJAutoProxy(exposeProxy = true)
3.4 集群下的问题
3.4.1 异常情况
通过加锁的方法在单机情况下可以保证一人一单的安全问题,但是在集群的情况下就无法保证;
3.4.2 锁失效的原理
syn 是依靠于jvm的,集群下每个节点都有自己的jvm,对于同一个jvm下syn 可以互斥,而不同jvm 无法进行互斥,导致锁失效;
由于现在我们部署了多个tomcat，每个tomcat都有一个属于自己的jvm，那么假设在服务器A的tomcat内部，有两个线程，这两个线程由于使用的是同一份代码，那么他们的锁对象是同一个，是可以实现互斥的，但是如果现在是服务器B的tomcat内部，又有两个线程，但是他们的锁对象写的虽然和服务器A一样，但是锁对象却不是同一个，所以线程3和线程4可以实现互斥，但是却无法和线程1和线程2实现互斥，这就是 集群环境下，syn锁失效的原因，在这种情况下，我们就需要使用分布式锁来解决这个问题。
五:总结和补充
- 高并发下秒杀问题,超卖问题;
- 悲观锁和乐观锁思想;
- CAS 和 自旋是两个概念,总有人混在一起谈论;
- 分布式锁的实质是利用第三方去解决多线程对共享资源的处理;
- 乐观锁适合修改数据,悲观锁可以修改数据,还可以用来插入数据;
- 碎碎念:感觉现在程序员之间真的是巨卷,不给其他人摸鱼的活路;
978
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
