秒杀系统设计思路

秒杀场景：比如选课系统。当然并发不多，只是举个例子。
1、每个老师只有40个名额，但是有4000个学生并发来选某一个老师得课。

原则: 把请求拦截在系统上游。延长请求过程时间。

一、前端验证：
1、js限制每秒只能发送一个请求。
2、按钮或连接点击之后几秒不能再点击，
3、验证码。
4、答题。答题要生成题库，复杂了。
5、不跳转页面，直接发送json数据，ajax异步操作，省html资源。

二、站点层：
限制用户id请求次数，一秒内只能透过10个请求，防止别人for循环请求。
具体：随手写的代码，没有经过测试。
关于这里，可以看这里：（一）redis限流

RedissonClient redisson = Redisson.create();
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        String id = "123";
        RBucket bucket = redisson.getBucket("blackId:" + id);
        // 是否是黑名单得
        if(bucket.get() == true){
            // 或者返回最近的一个请求的缓存
            return;
        }
        RAtomicLong idAccessNum = redisson.getAtomicLong(id);
       while (true){
            long num = idAccessNum.get();
            // 没有初始化，则设置过期时间
            // 这种方式，并非准确10秒10次就到了阈值，可能前10秒已经有9次，然后后10秒又请求了9次，
            // 最长可能会有18次。但是我们不需要准确的10次，所以无影响。
            // 如果想准确的统计，可以使用zset
            if(num == 0){
                idAccessNum.expire(10, TimeUnit.SECONDS);
            }
            // 超过了10次，则进入黑名单
            if(num > 10){
                // 加入黑名单，30秒之后不能再访问
                bucket.set(true, 30, TimeUnit.SECONDS);
                // 或者返回最近的一个请求的缓存
                return;
            }
            // 这里自旋，只针对同一个用户id，因为理论上同一个用户的请求是线性的，所以这里自旋
            // 不会对性能造成很大的影响
            boolean updateSuccess = idAccessNum.compareAndSet(num, num + 1);
            // 是否更新成功
            if(updateSuccess){
                break;
            }
        }
        // 放行

三、服务层
站点层拦截了一部分之后，到了服务层的就是真实的有效的请求了。
直接用redis收集已经下单的数量，库存有多少，则放多少请求进来，其他，都返回失败。

真正进来的的请求之后， 如果压力还大，可以进入mq，但是一旦进入了mq， 则说明是异步的，前端需要轮询查询订单是否下单成功(这里不适合websocket，因为这个轮询不会很久，没必要弄一个websocket），或者，容错性比较大，个别错误了无所谓。

也可以，进入线程池，但是进入线程池，一旦，服务挂了，数据就丢失了。

  String userId = "123";
        String storeId = "345";
        // 用户是否已经下过订单
        RBucket isOrdered = redisson.getBucket(storeId + ":" + userId);
        if(isOrdered.get() == 0){
            // 查询数据库，然后更新缓存，然后判断是否已经下过订单
        } else if(isOrdered.get() == 2){
            //已经下过订单
            return;
        }
        // 获取库存id
        RBucket storeBucket = redisson.getBucket(storeId + ":num");
        Long storeNum = storeBucket.get();
        // 缓存没有，则去查数据库
        if(storeNum == 0){
            // 查数据库
            // 没有则去查数据库（如果并发太高，这里有缓存穿透），可以分布式锁控制
            // 可以更新库存的时候，直接写入缓存。
        }
        RBucket inNumBucket = redisson.getBucket("storeId:inNum");
        while (true){
            Long inNum = inNumBucket.get();
            // 订单已经满了，则返回，抢购失败
            if(inNum >= storeNum){
                return;
            }
            // 减少库存
            boolean isSuccess = inNumBucket.compareAndSet(inNum, inNum - 1);
            if(isSuccess){
                break;
            }
        }
        // 下单成功
        // 如果压力还大，可以进入mq，但是一旦进入了mq，
        // 则说明是异步的，前端需要轮询查询订单是否下单成功
        // 这里保证幂等性，因为，如果同一个用户，落到两台机器上，则可能都会进入这里
        // 比如，insert唯一键，失败了，则回滚，并且，回滚库存，加1

        

四、对于读请求
就加缓存，加机器，再不行就限流抛弃一部分请求。
站点层，可以cdn加速。

五、业务折衷
1、比如，先抢到一个许可证，之后用这个许可证去购买。
这样，在第一个抢票环节，就直接往mq种放，不需要考虑消息是否执行完成，马上返回抢票成功。
缺点：用户体验极差。真的有这种并发量，还不如允许mq异步，然后页面跳转然后轮询呢。
2、对于当前库存数量，不精确数字，比如12306的显示有票。
3、把抢购，分时段，比如12306的分批放票。

六、问题：
一、如果一个用户多个请求，落到不同的服务器上，将会造成，下多个订单的问题。
解决方案：
1、数据库做唯一键，保证幂等性。
数据库插入失败之后，回滚把库存加回去

2、如果是update操作，j则加where条件乐观锁机制，返回影响0条，则回滚库存。
3、或者，分布式锁，锁住这个用户商品抢购，然后去查询是否下单成功。
总之，保证幂等性。