1

秒杀

1.限流

固定窗口算法:时间节点无法动态更新,即 set key expire 10s(1-11秒,2-12秒)处理不好

滑动窗口算法: zset member id score 10 解决时间节点问题 score即时间戳,可以动态获取(currentTime - score)时间内的总访问量,借此判断是否达标

漏桶算法:redis中好像有类似实现

令牌桶算法:Guava RateLimiter

2.降级(也叫做熔断)

spring cloud sentinel

3.缓存

3.1缓存一致性问题

A. 先更新Db,再delete redis

两个问题:

a .更新Db成功,删除缓存失败。导致redis中有脏数据(可以借助rocketmq不断重试解决)

b.1)缓存刚好失效

(2)请求A查询数据库,得一个旧值

(3)请求B将新值写入数据库

(4)请求B删除缓存

(5)请求A将查到的旧值写入缓存(根据耗时情况可以推算出概率比较低)

B 先删除缓存,再更新Db

​ (1)A线程删除缓存,写db更新为data2

​ (2)b线程查询发现缓存不存在

​ (3)b线程同步当前d b最新数据da ta1到redis

​ (4)a线程将数据data2写入DB .脏数据发生

3.2 解决方案

A.延时双删

先删除缓存,再更新DB,再异步删除缓存(通过rocketmq异步重试机制,确保删除成功)

B.订阅binLog机制

阿里开源的canal

3.3应用 秒杀实现

限流:zset滑动窗口限流

降级:spring cloud sentinel+open Feign熔断

缓存:

延时双删策略

1.库存扣减问题

提交订单时

付款时

提交订单时预先扣减库存,超时回复:定时任务轮训数据库没有付款的订单,超时订单归还库存

2.热点数据缓存

延时双删策略

3.库存防止超卖问题

乐观锁机制 update

update stock
   sale = sale + 1,
   version = version + 1,
  WHERE id = #{id,jdbcType=INTEGER}
  AND version = #{version,jdbcType=INTEGER}

或者
 
  update stock
   sale = sale + 1
  WHERE id = id
  AND sale={#sale}

悲观锁机制

在Service层给更新表添加一个事务,这样每个线程更新请求的时候都会先去锁表的这一行(悲观锁),更新完库存后再释放锁。可这样就太慢了,1000个线程可等不及。

beginTranse(开启事务)

try{

    //quantity为请求减掉的库存数量
    $dbca->query('update s_store set amount = amount - quantity where amount>=quantity and postID = 12345');

}catch($e Exception){

    rollBack(回滚)

}

commit(提交事务)

具体方案

  • 在系统初始化时,将商品的库存数量加载到Redis缓存中;
  • 接收到秒杀请求时,在Redis中进行预减库存,当Redis中的库存不足时(库存<0可以在内存中设置一个标志量boolean=已经卖光,就不需要再去请求redis增加网络开销了,分布式情况下通过zookeeper获得相应通知),直接返回秒杀失败,否则继续进行第3步;
  • 将请求放入异步队列中,返回正在排队中;
  • 服务端异步队列将请求出队,出队成功的请求可以生成秒杀订单,减少数据库库存(失败就会回滚,并且会恢复redis中的库存数据即加1),返回秒杀订单详情。
  • 当后台订单创建成功之后可以通过websocket向用户发送一个秒杀成功通知。前端以此来判断是否秒杀成功,秒杀成功则进入秒杀订单详情,否则秒杀失败。

Smile3k
197 声望22 粉丝