秒杀模块学习

秒杀模块

1. 秒杀接口优化

• 用户是否登陆
• 判断库存（备份在redis中一份）
  • 在初始化contoller接口的时候，就把商品id和对应的库存数存入到redis
• 判断是否已经秒杀到了
• 减缓存， 下订单（订单和秒杀订单）
  • 队列里面存的消息message，有两个变量用户和商品id,
  • receiver监听该队列，减库存，减库存成功了，根据用户和商品id,下订单
  • contoller需要的就是给队列发消息，最终给前端返回一个状态值（排队中）

• 前端轮询：是否生成了订单
  • 查询该笔订单是否存在
    • 存在，生成订单
    • 不存在，查看商品是否已经秒杀完了：
      • 没秒杀完，就是排队中
      • 完了，就返回该商品已经卖完了，并且在缓存中记录下该商品已经售罄了。goods_over+goodsId, true

2. 秒杀接口地址隐藏:

针对不同的用户，生成不同的秒杀地址，即秒杀地址上带一个参数，参数根据当前【用户id，商品id】随机生成，并保存在redis中，做秒杀的时候，先检查该参数是否匹配，只有匹配了才可以进行秒杀，不匹配是非法请求。

3. 验证码生成

点击秒杀之前，先让用户输入验证码。有2个目的：

• 防止机器人
• 用户输入验证码结果时间不同，因此分散用户的请求。

实现：

• 生成秒杀验证码，放在redis中
• 在秒杀的时候，先验证验证码，验证成功，删除ke y

4. 接口限流防刷

思路：

把每个用户访问接口的次数写入到缓存中，并设置失效时长s，因为可能每个方法设置的参数可能不同，所以可以通过注解+拦截器实现。

实现在 Controller 处理请求之前 先判断是否已经超过了设置的最大访问次数。

具体实现：

Step1: 在需要防刷的方法上加注解annotation，注解里设置两个参数时间seconds和最大访问次数maxCount

Step2: 添加拦截器(Interceptor)，在拦截器里先判断该方法上是否加了对应注解

Step3: 通过request中取得的method uri, 用户id 可以得到当前用户访问的该方法的次数

step4: 将该次数和注解里存的最大访问次数进行比较，看是否已经超过了限制的最大次数

Step5: redis中存放的key设置最大过期时间为注解的时间

Step5: 注册该拦截器

5. 分布式session

用户登陆成功后，给用户生成一个session_id标识这个用户，写在客户端cookie中，客户端访问服务器的时候会带上cookie，服务端在处理的时候，会从cookie中解码出session_id，从而取到用户信息。

---

为什么要使用分布式Session

Web应用在单机部署的情况下，Session是被单个应用服务器存储管理的，由于只有一个应用服务器，用户的所有请求都是通过它进行响应处理的，所以能够很容易实现会话跟踪和保持。随着业务量的增长，系统架构需要做出调整以适应发展的需要，可能会使用分布式架构或微服务架构，无论使用哪种架构方式，应用系统单机部署的模式已经不能满足需求，所以会将应用系统部署到多台应用服务器上，用户的请求也会通过负载均衡转发到某个具体应用服务器上执行，可能会出现在A1系统登录后创建并保存Session，再次发起请求，请求被转发到A2系统上显示未登录的情况，此时单机部署模式下的Session机制已不能满足要求。所以，在分布式架构或微服务架构下，必须保证一个应用服务器上保存Session后，其它应用服务器可以同步或共享这个Session。

分布式session管理实现方案

分布式Session有如下几种实现方式。

1.Session复制

在支持Session复制的Web服务器上，通过修改Web服务器的配置，可以实现将Session同步到其它Web服务器上，达到每个Web服务器上都保存一致的Session。
优点：代码上不需要做支持和修改。
缺点：需要依赖支持的Web服务器，一旦更换成不支持的Web服务器就不能使用了，在数据量很大的情况下不仅占用网络资源，而且会导致延迟。
适用场景：只适用于Web服务器比较少且Session数据量少的情况。
可用方案：开源方案tomcat-redis-session-manager，暂不支持Tomcat8。

2.Session粘滞

将用户的每次请求都通过某种方法强制分发到某一个Web服务器上，只要这个Web服务器上存储了对应Session数据，就可以实现会话跟踪。
优点：使用简单，没有额外开销。
缺点：一旦某个Web服务器重启或宕机，相对应的Session数据将会丢失，而且需要依赖负载均衡机制。
适用场景：对稳定性要求不是很高的业务情景。

3.Session集中管理

在单独的服务器或服务器集群上使用缓存技术，如Redis存储Session数据，集中管理所有的Session，所有的Web服务器都从这个存储介质中存取对应的Session，实现Session共享。
优点：可靠性高，减少Web服务器的资源开销。
缺点：实现上有些复杂，配置较多。
适用场景：Web服务器较多、要求高可用性的情况。
可用方案：开源方案Spring Session，也可以自己实现，主要是重写HttpServletRequestWrapper中的getSession方法，博主也动手写了一个，github搜索joincat用户，然后自取。

4.基于Cookie管理

这种方式每次发起请求的时候都需要将Session数据放到Cookie中传递给服务端。
优点：不需要依赖额外外部存储，不需要额外配置。
缺点：不安全，易被盗取或篡改；Cookie数量和长度有限制，需要消耗更多网络带宽。
适用场景：数据不重要、不敏感且数据量小的情况。

总结

这四种方式，相对来说，Session集s管理更加可靠，使用也是最多的。