likes
comments
collection

抢购业务的技术方案

作者站长头像
站长
· 阅读数 18

总体架构方案

网络拦截: DNS优化, SLB负载均衡,网关封IP限速

业务拦截: ID限速, 验证码, 只吸收前面N个请求,后面的全拒绝;

Redis拦截: 库存不超发,保证限购

接口拦截: 尽量减少业务检查,判断黑名单

MQ+MYSQL: 异步处理落库情况;

Redis List方案 + Incrby方案

  1. 从缓存读取出活动信息
  2. 判断活动开始时间和结束时间
  3. redis内无库存就直接返回无库存,活动结束
  4. 读取 UID+活动ID的 参与次数 达到限制就返回限制
  5. 使用Incrby 写入 UID+活动ID的 参与次数,判断返回的次数是否超过限购次数,超过则返回限制
  6. 写入DB(或者用MQ推送给DB削峰落库)

第四点虽然redis是单线程的,但是客户端是多个的,所以第四点的读取和第五点的使用,两个不能同时具有原子性, 必须以 incrby结果为准;

比如一人限购一个,就算某用户第二个请求进来了,把 UID+活动ID 的值 incrby 为2 ,那么这个人返回的也是 “一人只可以购买一个”,对于业务无损;

如果出现Redis崩溃或者Mysql崩溃等异常情况,等待服务恢复后, 可以直接从DB里面的购买记录和库存信息简单同步到redis里面,无需开发人员进行过多操作

Redis List方案支持库存编号模型,如果所有的SKU本身无编号意义或者发货才确定库存,可以使用 Incrby控制库存 + Incrby 控制个人限购数量