总体架构方案
网络拦截: DNS优化, SLB负载均衡，网关封IP限速
业务拦截： ID限速， 验证码， 只吸收前面N个请求，后面的全拒绝;
Redis拦截: 库存不超发，保证限购
接口拦截： 尽量减少业务检查，判断黑名单
MQ+MYSQL: 异步处理落库情况;
Redis List方案 + Incrby方案
- 从缓存读取出活动信息
- 判断活动开始时间和结束时间
- redis内无库存就直接返回无库存，活动结束
- 读取 UID+活动ID的 参与次数 达到限制就返回限制
- 使用Incrby 写入 UID+活动ID的 参与次数，判断返回的次数是否超过限购次数，超过则返回限制
- 写入DB（或者用MQ推送给DB削峰落库）
第四点虽然redis是单线程的，但是客户端是多个的，所以第四点的读取和第五点的使用，两个不能同时具有原子性, 必须以 incrby结果为准;
比如一人限购一个，就算某用户第二个请求进来了，把 UID+活动ID 的值 incrby 为2 ，那么这个人返回的也是 “一人只可以购买一个”，对于业务无损；
如果出现Redis崩溃或者Mysql崩溃等异常情况，等待服务恢复后， 可以直接从DB里面的购买记录和库存信息简单同步到redis里面，无需开发人员进行过多操作
Redis List方案支持库存编号模型，如果所有的SKU本身无编号意义或者发货才确定库存，可以使用 Incrby控制库存 + Incrby 控制个人限购数量
mysql
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。