中间件(四)：秒杀系统架构设计

目录

写在前面

1、合理的架构、有限的机器资源优化

​2、方案一：堆机器

3、方案二：架构设计

3.1、高并发的商品详情页请求

3.2、商品团队的秒杀架构优化：页面数据静态化

3.3、商品团队的秒杀架构优化：多级缓存

总结：

3.4、基于MQ的秒杀订单系统架构

3.4.1、用答题的方法避免作弊抢购以及延缓下单

3.4.2、为秒杀独立出来一套订单系统

3.4.3、基于Redis实现下单时精准扣减库存

 3.4.4、抢购完毕之后提前过滤无效请求

3.4.5、瞬时高并发下单请求进入RocketMQ进行削峰

 总结

---

写在前面

最近公司的运营花了很多钱做活动拉新用户，公司APP的日活用户一直在增长 现在已经明显发现每天高峰时间公司搞秒杀活动的时候，比以前有更多的用户在某个时间点蹲守在手机APP前。特价秒杀商品时间一 到，就有大量的并发请求过来，系统压力非常大

1、合理的架构、有限的机器资源优化

因为订单系统目前部署了20台4核8G的机器，整个集群抗每秒上万请求压力是可以的，单台机器500是可以的。即使后续用户量越来越大，大不了就是给订单系统加更多的机器就可以了。

         但是这里有一个问题，20台订单系统的机器都是访问同一台机器上部署的MySQL数据库的，那一台数据库服务器目前经常在晚上秒杀活动的时候，瞬时并发量达到上万。所以最近几天明显发现数据库的负载越来越高，比如CPU、IO、内存、磁盘的负载几乎都快要到极限