总体架构计划
网络拦挡: 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 管制集体限购数量