秒杀架构设计

文章目录

• 一、秒杀商品详情页--架构设计
• 二、秒杀下单--架构设计

一、秒杀商品详情页–架构设计

最简单的架构

使用redis缓存加快查询速度

将非常热点、不容易变的数据放入jvm缓存中，避免网络问题导致redis查询出问题

用多台机器抗住高并发场景，搭配nginx做负载均衡

nginx查询缓存，避免查询打到后端服务，加快速度

将页面的静态资源缓存到CDN上，比从服务器取静态资源快

后端将页面完全静态化，将静态化的资源全部放在CDN上。其实就是提前将后端数据放到html页面中，数据提前渲染到页面，可以少很多后端请求，提高了速度。

二、秒杀下单–架构设计

最简单的下单架构

扣减库存的 *** 作放在redis中，可以避免高并发时修改数据库，出现锁竞争的情况。

在缓存更新后使用异步mq更新数据库，可以搭配分布式事务，使用rocketMq来实现，解决缓存数据库数据不一致的问题。

如果1000万人参与秒杀，只有100万商品，另外900万个人的请求也会到系统上，对系统压力很大，可使用令牌的概念进行限制。
需要注意，令牌的数量需要比商品数量多一点。以免有些用户下单未付款，导致其他人不能参与秒杀。

如果秒杀的流量依然很大，需要对后端接口进行限流，免得请求过多将系统打垮。

如果服务同时只能处理100个线程，但是秒杀时可能有1000个请求，可以将请求放在队列中，一次只取100个进行处理，保证cpu能处理的线程数量和从队列拿出来的队列数量一致，保护系统，在接口做“队列泄洪”。

加入熔断降级 *** 作，避免流量过大。

参考资料：b站IT老哥技术视频，点击该链接