1 查看商品详情页
接下来介绍并发量从低到高设计查看商品详情页
第一种:
用户 -> 浏览器 -> 后端系统 -> MySQL (弊端:无法抗住高并发)
第二种
用户 -> 浏览器 -> 后端系统 -> Redis -> MySQL(通过缓存可以加快用户查看商品详情的速度,但还有优化空间)
第三种
用户 -> 浏览器 -> 后端系统 -> JVM内存 -> Redis -> MySQL (在加入一级缓存来减少与Redis的交互,减少IO,也可以优化速度;但是,加入JVM内存它能抗住的并发也是有限的,如果想让它抗住10万并发它肯定不行)
第四种
假设单台机器能抗住1万并发的访问,那么部署多台服务,通过Ngingx来做负载均衡将请求转发到各个服务中;同时在nginx这一层可以直接访问Redis,将商品详情通过这一步来完成
第五种
商品详情页中有很多静态资源,例如CSS JS HTML等,如果这些静态资源都到服务器上获取,则会浪费服务器的性能;这时我们可以将这些静态资源缓存到 CDN(内容分发网络) 上去,这样浏览器就可以直接到CDN上取静态资源了,要比去服务器上取静态资源要快的多。
但还有一种优化空间,就是这个页面显示的数据还得去后端查询出来;
第六种
利用页面静态化技术,提前把后端的数据渲染到页面上,让后把这个渲染好的页面放到CDN给用户访问,这样用户看到的页面就有数据了,就不用到后端去请求数据了,从而减轻服务器的压力;
2 秒杀下单
第一种
用户发送秒杀下单请求 -> 浏览器 -> 后端系统(创建订单,扣减库存)-> MySQL
弊端:高并发下操作数据库会产生锁竞争,导致数据不安全即系统整体性能下降;
第二种
可将库存数量提前读取到 Redis 中,然后扣减库存的操作都在 Redis中进行;这种操作需要解决缓存与数据库数据保持一致问题;
第三种
添加消息队列,扣减库存的操作还是在 Redis 中进行,将扣减库的信息发给 mq,然后 mq 去通知 MySQL 去扣减库存,用这种异步的方式去同步数据库中的库存;但是这边还涉及到两个问题,一个是 MySQL 消费mq消息失败怎么办,另一个是数据库创建订单时失败了怎么办;这边就涉及到了分布式事务,可以使用支持事务的 Rocket mq
第四种
解决库存商品被秒杀完,用户还不停地秒杀商品的问题:
可以添加一个令牌的概念,即用户在秒杀之前需要先到系统获取一个令牌,再去秒杀商品;如果用户没有带着令牌去请求秒杀接口则直接返回失败;那么限制这个令牌数就可以防止用户不断地发送秒杀请求了;另外这个令牌数一般要设置比秒杀商品数大,需要防止一些用户秒杀到了商品不付款的情况;
第五种
虽然加入了令牌的概念,但是我们的秒杀活动不可能只秒杀一件商品,这个秒杀的接口承载的压力还是很大,那么我们要加入限流的操作,比如说我们的系统只能承载10000的并发,那么我们就可以进行限流,比如限流到8000qps,这个限流的好处是不至于让太大的流量把系统打垮。
第六种
尽管做了8000qps限流操作,如果发送意外情况,这个8000qps的请求也很可能打垮系统,这时我们需要做一个熔断降级的操作去短暂保护我们的系统,暂时只能让一小部分的流量去请求我们的接口,等接口恢复时再把接口完全开放出来,同时配合降级逻辑即提示系统繁忙请稍后再试的操作;且运维的人员也要实时检测系统的可用性,一旦系统被打垮,需要给我们整一个秒杀系统集群动态地添加节点去抗高并发;