这是我参与「第五届青训营」笔记创作活动的第 11 天
|| 🎶今日笔记🎶 ||
系统设计
- 服务单一职责
- 解决方案
- 限流
前言-->
首先设计一个系统之前，我们需要先确认我们的业务场景是怎么样子的，我就假设一个
场景-->
我们现在要卖100件下面这个婴儿纸尿裤，然后我们根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人。
这我们的服务器哪里顶得住！说真的直接打DB肯定挂。但是，解决问题的方法大于问题本身
服务单一职责
设计个能抗住高并发的系统，我认为还是得单一职责。
大家都知道现在设计都是微服务的设计思想，然后再用分布式的部署方式
也就是我们下单是有个订单服务，用户登录管理等有个用户服务等等，那为啥我们不给秒杀也开个服务，我们把秒杀的代码业务逻辑放一起。
单独给他建立一个数据库，现在的互联网架构部署都是分库的，一样的就是订单服务对应订单库，秒杀我们也给他建立自己的秒杀库。
至于表就看大家怎么设计了，该设置索引的地方还是要设置索引的，建完后记得用explain看看SQL的执行计划。
单一职责的好处就是就算秒杀没抗住，秒杀库崩了，服务挂了，也不会影响到其他的服务。（强行高可用）
秒杀链接：
我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了，那又有人要说了我做个时间的校验就好了呀，但是，知道链接的地址比起页面人工点击的还是有很大优势。
我知道url了，那我通过程序不断获取最新的北京时间，可以达到毫秒级别的，我就在00毫秒的时候请求，我敢说绝对比你人工点的成功率大太多了，而且我可以一毫秒发送N次请求，搞不好你卖100个产品我全拿了。
那这种情况怎么避免？
简单，把URL动态化，就连写代码的人都不知道，你就通过MD5之类的加密算法加密随机的字符串去做url，然后通过前端代码获取url后台校验才能通过。
解决方案
Redis集群：
之前不是说单机的Redis顶不住嘛，那简单多找几个兄弟啊，秒杀本来就是读多写少，那是不是瞬间想起来我之前提到过的，Redis集群，主从同步、读写分离，我们还搞点哨兵，开启持久化直接高可用。
Nginx：
Nginx大家想必都不陌生了吧，这是高性能的web服务器，并发也随便顶几万不是梦，但是我们的Tomcat只能顶几百的并发呀，那简单呀负载均衡嘛，一台服务几百，那就多搞点，在秒杀的时候多租点流量机。
这样一对比是不是觉得你的集群能顶很多了。
恶意请求拦截也需要用到它，一般单个用户请求次数太夸张，不像人为的请求在网关那一层就得拦截掉了，不然请求多了他抢不抢得到是一回事，服务器压力上去了，可能占用网络带宽或者把服务器打崩、缓存击穿等等。
资源静态化：
秒杀一般都是特定的商品还有页面模板，现在一般都是前后端分离的，所以页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。
按钮控制：
有没有发现没到秒杀前，一般按钮都是置灰的，只有时间到了，才能点击。
这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器，然后还没到秒杀的时候基本上服务器就挂了。
这个时候就需要前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。
限流
限流这里我觉得应该分为 前端限流 和 后端限流 。
前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击，这也是保护服务器的一种手段。
后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。
Tip：真正的限流还会有限流组件的加入例如：阿里的Sentinel、Hystrix等。
~ End ~
