Java 商品抢购系统设计，实现与优化

哇咔咔负负得正

已于 2022-10-13 09:33:50 修改

阅读量1.8k

点赞数

分类专栏： Spring Boot 文章标签： java mybatis 开发语言

于 2022-10-05 13:30:29 首次发布

本文链接：https://blog.csdn.net/qq_39906884/article/details/127052332

版权

Spring Boot 专栏收录该内容

16 篇文章 0 订阅

订阅专栏

Java 商品抢购系统设计，实现与优化

参考教程：https://www.bilibili.com/video/BV1sf4y1L7KE

0. 使用技术

Java 1.8
SpringBoot 2.7.4
RabbitMQ 3.11
Redis 6.2.7
Mybatis-plus 3.5.2
MySQL 5.7

1. 流程

功能开发
系统压测
分布式会话
优化
- 页面优化
- 服务优化
- 安全优化

2. 高并发带来的一些问题

可能会遇到黄牛，大量并发写和并发读。

因此设计系统要保证高可用，保证数据一致性，高性能。

3. 参考配置

Druid 数据源配置属性说明

MybatisX逆向工程

Mybatis 执行器

4. 分布式 Session 问题

多台 Tomcat 配合 Nginx 出现用户登录的问题。

Nginx 使用默认的负载均衡策略（轮询），请求将会按照时间顺序逐一分发到后端应用上。

比如，首先用户在 Tomcat1 上登陆后，用户信息保存在 Tomcat1 的 Session 中。过了一会请求被 Nginx 分发到了 Tomcat2 上，因为 Tomcat2 上的 Session 没有用户信息，此时又要登录。

4.1 可使用的解决方案

4.1.1 Session复制

优点：

无需修改代码，只需要修改 Tomcat 配置

缺点：

Session 同步传输占用内网贷款
多台 Tomcat 同步性能指数下降
Session 占用内存，无法有效水平扩展
- 我加机器就是为了扩展内存，你这 Session 同步，每台机器还是占用那么多内存，太冗余了

4.1.2 前端存储

优点：

不占服务器内存

缺点：

存在安全风险
- Cookie 是明文的，不安全
数据大小受到 Cookie 限制
占用外网带宽
- 前端到后端传送对象也需要占用带宽的

4.1.3 Session 粘滞

优点：

无需修改代码
服务端可以水平扩展

缺点：

增加新机器，会重新 Hash，导致重新登陆
应用重启，需要重新登陆

4.1.4 后端集中存储

优点：

安全
容易水平扩展

缺点：

增加复杂度
需要修改代码

4.2 选择第四种方案（Redis）

docker 安装 Redis 6.2.7

客户端使用 Another Redis Desktop Manager 1.5.8

4.2.1 示例

set key value [ex 10 | px 10000] [nx | xx]

nx 表示当不存在该 key 设置成功
xx 表示存在该 key 设置成功
ex 10 十秒后过期
px 10000 一万毫秒（即十秒）后过期

4.3 SpringSession 实现方式（抛弃这种实现）

当执行 session.setAttribute() 时会自动导入 Redis
在这里插入图片描述

4.4 直接用 Redis 存储信息的实现方式（使用该实现）

首先实现序列化方法，默认的 JDK 序列方法可读性有点差。采用 Jackson 的序列化。

首次登录先存 Cookie，然后在 Redis 中存储 {“user:cookie”：userObject}，下一次访问的时候直接拿着本地的 Cookie 去 Redis 取信息。

如果每个页面都需要判断是否登录太麻烦了。如何解决？

先配置用户参数解析器，在解析器中通过 cookie 向 Redis 中取信息，然后直接将对象变为控制器的入参即可。

5. 优化前 Jmeter 压测记录

5.0 测试环境

Windows 10，Intel i7 7700HQ，内存 16G
Linux CentOS 7（虚拟机环境）4 核心，内存 4G

redis 单节点，mysql

5.1 获取商品列表信息

设置线程数 5000，每个线程重复请求 10 次。

重复此操作 3 次。

5.1.1 Windows 测试

QPS：1498.9

在这里插入图片描述

5.1.2 Linux 测试

QPS：832.8

在这里插入图片描述

5.2 秒杀

设置商品为 10。

设置线程数 1000，每个线程重复请求 10 次。

重复此操作 3 次。

5.2.1 Windows 测试

QPS：1111.9

在这里插入图片描述

可以看到数据库中超卖了 2 件：

在这里插入图片描述

订单表和秒杀订单表中的数据条数各有 338 条：

在这里插入图片描述

5.2.2 Linux 测试

QPS：812.1

在这里插入图片描述

数据中超卖了 18 件：

在这里插入图片描述

订单表和秒杀订单表中的数据条数各有 196 条数据：

在这里插入图片描述

5.3 总结

可以看到在并发环境下会出现超卖问题，以及商品库存小于 1 的时候还会加入订单。接下来将基于此进行优化，解决线程同步以及提高 QPS。

6. 初次优化

6.1 对象 JSON 缓存

每次获取商品列表或者某件商品的信息的时候，先从 Redis 中取，若 Redis 中没有，再去数据库找，并加入 Redis 缓存中。

// 先从 Redis 中取缓存, 若返回的对象不为空则直接返回对象
ValueOperations valueOperations = redisTemplate.opsForValue();
List<GoodsVo> goodList = (List<GoodsVo>) valueOperations.get("goodsList");
if (!ObjectUtils.isEmpty(goodList)) {
    return  goodList;
}
// 若 Redis 中没有则从数据库加载
List<GoodsVo> list = goodsService.findGoodVo();
// 设置失效时间 5 min
valueOperations.set("goodsList", list, 5, TimeUnit.MINUTES);

return list;