秒杀系统设计

秒杀系统设计

会出现的问题

高并发

• 秒杀就是短时间的，瞬间用户极多。
• Redis也就能抗住几万的QPS，在大量请求下：缓存雪崩、缓存击穿、缓存穿透都是可能发生的，

超卖

• 多卖出了商品

恶意请求

• 脚本恶意请求

连接暴露

• 导致可以提前请求访问
• 或者写脚本压秒访问

数据库

• 几秒钟十几万的QPS，直接打到数据库上，可能导致数据库挂掉，要是没有降级、限流、熔断，别的一起挂掉。

解决

服务单一职责

把秒杀单独形成一个服务，单独建立数据库，万一秒杀挂掉也不至于影响其他服务

秒杀连接加盐

• URL动态化，可以通过MD5之类的加密算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过

  public static String getKuaishouSign(String url){
          try {
              //初始化MessageDigest
              MessageDigest md5=MessageDigest.getInstance("MD5");
              //更新
              md5.update((url).getBytes("UTF-8"));
              //生成摘要
              byte[] b=md5.digest();
              int i;
              StringBuffer buf=new StringBuffer();
              for(int offeset=0;offeset<b.length;offeset++){
                  i=b[offeset];
                  if(i<0){
                      i+=256;
                  }
                  if(i<16){
                      buf.append("0");
                  }
                  buf.append(Integer.toHexString(i));
              }
              url=buf.toString();
              System.out.println(url);
          }catch (Exception e){
  
          }
          return url;
      }
  

Redis集群

• Redis集群
• 主从同步
• 读写分离
• 哨兵
• 持久化
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xE0dEKDK-1582682829457)(https://raw.githubusercontent.com/iszhonghu/Picture-bed/master/img/20200119152357.png)]

Nginx

资源静态化

​ 秒杀一般都是特定的商品还有页面模板，现在一般都是前后端分离的，所以页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。

按键控制

• 提前置灰

限流

• 前端限流
  • 不允许持续点击
• 后端限流
  • 直接关闭后续无效的请求

库存预热

• 提前将商品库存加载到Redis中，后续在异步修改数据库

限流、降级、熔断、隔离

​ 限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。

削峰填谷