秒杀系统设计
会出现的问题
高并发
- 秒杀就是短时间的,瞬间用户极多。
- 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中,后续在异步修改数据库
限流、降级、熔断、隔离
限流,顶不住就挡一部分出去但是不能说不行,降级,降级了还是被打挂了,熔断,至少不要影响别的系统,隔离,你本身就独立的,但是你会调用其他的系统嘛,你快不行了你别拖累兄弟们啊。