秒杀

流程#

查询优惠券

判断券的库存

=》充足扣减 不足报错

超卖问题#

只要在线程1扣减前查询，都会扣减

乐观锁性能比悲观锁性能好

版本号法#

使用一个变量判断是否变化来判断 ==》利用库存代替版本

CAS#

乐观锁弊端：成功率太低

==》对于库存问题：不用select相等，只要>0就行

==》对于必须相等的cas情况：分段锁，将100个库存分到10个表里面，到10个表里面分别去抢，成功率大幅度提高

一人一单#

就是查询同个用户同张优惠券的订单是否存在

和库存超卖逻辑一样，大家都查询到为0

这里区别是判断数据是否存在，不是判断是否修改，只能用悲观锁

对整个流程抽象，对每个用户加锁

锁的释放时机#

上面方法先获取事务再获取锁，锁释放后事务可能没有提交

先获取锁再提交事务，才能保证事务安全

事务是否生效#

不懂spring

所以说这样逻辑实际变成了判断能不能买，有没有买过，能买的话在执行扣库存和下订单的操作 ==》double check库存是否真的能够减少

集群下的线程没锁住#

每个JVM都有自己的锁，导致每个锁都有一个线程获取

分布式锁#

考虑JVM外部的锁监视器

多进程可见

互斥：难点，必须保证只有一个人获取到，其他人都失败

常用的分布式锁#

Redis分布式锁流程#

锁超时误删#

在删除时要判断下==》在存入时要存一个线程标识

分布式锁的原子性问题#

判断锁标识和释放不是一起执行，没有保证原子性，删掉的锁不是自己的

用setnx实现分布式锁的缺点#

可重入锁#

保存一个访问的次数

hash结构没有set nx

获取锁流程

锁重试和watch dog#

主从一致性问题 - 联锁#

主节点的锁没有同步到从节点上

解决方法就是不用主从，建立多个独立的锁

只有在每一个节点都拿到锁才能成功？？

这样宕机了一台获取锁就不会成功

Redisson总结#

Redis优化秒杀性能#

将两个不用更改数据库的操作独立处理

在redis中执行判断和扣减，异步的执行下单和减库存的操作

基于Redis完成秒杀资格判断#

List模拟消息队列#

拿出消息后消息发送时丢失了

PubSub的消息队列#

三种通配符

天生阻塞且可以多个消费者拿到消息

基于stream的消息队列-单消费模式#

基于stream的消费队列-消费者组#

注意改ID就是从pendinglist中读

用ACK确认

功能完善

消息队列对比#