Java高并发秒杀平台（Redis + RabbitMQ）

Seconds-Kill

本项目是一个模拟高并发环境下基于 SpringBoot 的秒杀购物平台。为了减少对数据库的直接访问，通过 Redis 实现了缓存优化；并通过 RabbitMQ 消息中间件来接收大量的并发请求，实现异步和削峰，然后再慢慢地更新数据库。最后通过 Jmeter 压测工具，可以很好地对比优化前后的 QPS…

项目的源代码：基于 SpringBoot 的高并发秒杀平台

quick-start

• 项目的基本配置及背景
• 明文密码两次 MD5 加密
• 分布式 Session
• 秒杀功能开发
• 第一次压测
  • Jmeter 快速入门
  • 自定义变量模拟多用户
  • 商品查询与秒杀下单压测
• 页面级高并发秒杀优化
  • 商品列表页缓存实现
  • 热点数据对象缓存
  • 解决超卖问题
• 服务级高并发秒杀优化
  • 集成 RabbitMQ
  • Redis 预减库存和RabbitMQ 异步下单
• 第二次压测
• 写在最后

项目的基本配置及背景

项目用的是 SpringBoot 2.1.5、thymeleaf 2.0.4、MyBatis 1.3.2、MySQL 8.0、最新版本的 Redis、Jmeter 压测工具和 RabbitMQ 消息中间件，其中 Redis、Jmeter 和 RabbitMQ 的相关配置是部署在虚拟机上，最后将项目打成 jar 包在虚拟机上运行。具体的环境配置过程稍微有点复杂，网上有具体博客可作参考，这里不加详述。

本项目是一个秒杀系统，秒杀与其他业务最大的区别在于秒杀的瞬间：

1. 系统的并发量会非常的大

2. 并发量大的同时，网络的流量也会瞬间变大

关于第一点，核心问题在于如何在大并发的情况下能保证 DB 能扛得住压力，因为大并发的瓶颈就在于 DB。如果说请求直接从前端透传到 DB，显然，DB 是无法承受几十万上百万甚至上千万的并发量的。所以，我们能做的只能是减少对 DB 的访问，比如前端发出了1000万个请求，通过我们的处理，最终只有100个会访问 DB，这样就可以了！针对秒杀这种场景，因为秒杀商品的数量是有限的，这种做法刚好适用！

关于第二点，最常用的办法就是做页面静态化，也就是常说的前后端分离：把静态页面直接缓存到用户的浏览器端，所需要的数据从服务端接口动态获取。这样会大大节省网络的流量，再加上 CDN，一般不会有大问题。

如何减少DB的访问？

假如某个商品可秒杀的数量是10&#