抢购业务的技术方案

总体架构方案

网络拦截: 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 控制个人限购数量