一些高并发场景自己的思考

每天提升自己，否则n年后你还是老样子！

目录

• 一、电商售卖商品
• 二、抢红包

同事分享的文档：

1. https://doc.weixin.qq.com/doc/w3_AbEAYwZdAOkvPOKpnjkQfaoUjEvGu?scode=ANAAyQcbAAgVJz11FrAbEAYwZdAOk

默认背景：100W的QPS

一、电商售卖商品

• 场景一：1个sku，库存10万（普通的高并发购买）

  1. 库存使用redis计数。生单页提交时校验库存是否充足
     1. 大库存很少会出现百万QPS，因此redis的key使用1个即可
     2. 为了防止存储key的那台redis宕机，因此redis采用分桶，即使用2个redis节点分片（库存要求没那么严格的话，直接批量读到内存中，使用内存缓存判断）
     3. 根据userId路由到某一个key，如果那个key库存没了，则再路由到另一个key
  2. 校验库存通过后就可以进行创建订单，然后重新计算用户需要付的金额，跳转到待支付页面执行后续流程即可

  至于当前key的分桶个数，可以按照每个桶存储5万库存来划分。

  划分后将这个信息sky划分几个桶的信息存储到redis上。

  校验用户库存是否充足时，使用先读redis，然后将信息存储在本地内存，按照分桶个数进行hash。

• 场景二：100个sku，每个库存10万

  不同sku使用不同redis分桶存储即可

• 场景三：1个sku，库存10个

  • 分析：这种高QPS小库存的属于秒杀场景，需要满足未到秒杀时间，访问链接拒绝无效

  • 设计

    1. 将剩余库存数，存储到redis。根据直播间预估人数划分分片存储个数（防止极热点key，导致响应变慢）
    2. 抢到库存后返回一个服务端的token，客户端带着这个token访问后续创建订单页面
    3. 服务端校验token合法则进行后续流程

    如果预估qps将特别巨大的，可以在各个节点进行限流

    1. 客户端随机限流
    2. 服务端有专门的token服务器，用于客户端请求token的（100W --> 10W）
    3. 客户端未取到token的直接显示失败，抢到的则进行服务端真实下单token的返回
    4. 客户端带着真实抢购的token进行支付购买即可

• 场景四：100个sku，每个库存10个

  不同sku使用不同redis分桶存储即可

• 场景五：1个sku，总库存10万，前10个库存金额为1元，其余都是100元

  思路：使用token，有token的1元，没token的100元

  1. 客户端提交订单
  2. redis库存校验通过，则返回token，否则返回空
  3. 客户端带着返回值请求提交订单
  4. 服务端校验token合法则待支付1元，否则待支付100元

二、抢红包

• 场景一：直播间主播发10个红包

  • 主播包红包
    1. 将10个红包记录记录到db
    2. 创建redis的list集合存储这10个记录的id和金额
  • 观众抢红包
    1. lpop未抢到则返回已抢集合
    2. lpop抢到
       1. 加入已抢集合（redis的list）
       2. 更新db此人的userId
       3. 异步mq
       4. 消费mq执行转账
          • 先改status为转账中，然后执行转账，成功则修改status为成功，失败则修改为失败
       5. 定时判断是否存在失败和转账中的（异常情况特别处理）