redis秒杀系统实现

秒杀系统需求分析

简介：采用大厂需求分析步骤对秒杀需求功能分析

• 功能核心点

  • 经典互联网商品抢购秒杀功能

秒杀系统

• 功能api

  • 商品秒杀接口

• 数据落地存储方案

  • 通过分布式redis减库存
  • DB存最终订单信息数据

• api性能调优

  • 性能瓶颈在高并发秒杀
  • 技术难题在于超卖问题

秒杀分析

秒杀系统功能步骤梳理

简介：后端秒杀功能步骤梳理

• 利用 Redis 缓存incr拦截流量

  • 首先通过数据控制模块，提前将秒杀商品缓存到读写分离 Redis，并设置秒杀开始标记如下：

"skuId_start": 0 //开始标记0表示秒杀开始
"skuId_count": 10000 //总数
"skuId_access": 12000 //接受抢购数

*   秒杀开始前，服务集群读取 goodsId_Start 为 0，直接返回未开始。

*   服务时间不一致可能导致流量倾斜

*   数据控制模块将 goodsId_start 改为1，标志秒杀开始。

*   当接受下单数达到 sku_count*1.2 后，继续拦截所有请求，商品剩余数量为 0

• 利用Redis缓存加速库存扣量

    "skuId_booked": 10000 //总数0开始10000  通过incr扣减库存，返回抢购成功

• 将用户订单数据写入mq

• 监听mq入库

秒杀系统功能api实战(上)

简介：后端秒杀网关流量拦截层功能开发

• 先判断秒杀是否已经开始

  • 初始化时将key SECKILL_START_1 value 0_1554046102存入数据库中

• 利用 Redis 缓存incr拦截流量

  • 缓存拦截流量代码编写

  • 用incr方法原子加

  • 通过原子加判断当前skuId_access是否达到最大值

  • 思考：是否需要保证获取到值的时候和incr值两个命令的原子性

    • 保证原子性的方式，采用lua脚本
    • 采用lua脚本方式保证原子性带来缺点，性能有所下降
    • 不保证原子性缺点，放入请求量可能大于skuId_access

代码：

service秒杀主体代码 流量拦截

秒杀系统功能api实战(中)

简介：后端秒杀信息校验层功能开发布隆过滤器实现重复购买拦截

• 订单信息校验层

  • 校验当前用户是否已经买过这个商品

    • 需要存储用户的uid
    • 存数据库效率太低
    • 存Redis value方式数据太大
    • 存布隆过滤器性能高且数据量小

• 校验完通过直接返回抢购成功

使用布隆过滤器判断用户是否已经购买过该产品

秒杀系统功能api实战(下)

简介：后端秒杀信息校验层功能开发lua脚本实现库存扣除

• 库存扣除成功，获取当前最新库存

• 如果库存大于0，即马上进行库存扣除，并且访问抢购成功给用户

• 考虑原子性问题

  • 保证原子性的方式，采用lua脚本
  • 采用lua脚本方式保证原子性带来缺点，性能有所下降
  • 不保证原子性缺点，放入请求量可能大于预期值
  • 当前扣除库存场景必须保证原子性，否则会导致超卖

• 返回抢购结果

  • 抢购成功
  • 库存没了 ，抢购失败

lua脚本：

秒杀lua脚本 redisService执行lua代码 调用service代码 测试 redis检查确实有1个预定