SpringBoot+RabbitMQ+Redis 开发一个秒杀系统,细节打满(附源码)

程序员追风 2023-10-12 22:00 发表于湖南

收录于合集#秒杀系统2个


上方蓝色“程序员追风”,选择“设为星标”

回复“资料”获取整理好的面试资料


原文:
blog.csdn.net/jike11231/article/details/126818020

一、简易版秒杀SeckillProject系统简介

本项目是参考网上资料,整理开发而成,项目代码中加入了自己的理解和实现。基于SpringBoot框架开发,实现的功能主要是登录、商品列表、商品详情、秒杀商品,订单详情等功能,涉及异步下单、热点数据缓存、解决超卖等技术实现。

在系统业务处理中,使用到分布式session维持会话、Redis预减库存降低数据库访问压力,消息队列异步下单(削峰)、客户端轮询结果、接口限流防刷等技术。

开发技术
  • 后端:SpringBoot 、MyBatis 、 MySQL、RabbitMQ、Redis

  • 前端:Html、JQuery 、Thymeleaf

二、实现细节记录

1、用户密码两次MD5加密

第一次MD5加密:防止用户明文密码在网络进行传输

第二次MD5加密:防止数据库被盗,避免通过MD5反推出密码,双重保险

2、分布式session维持会话

后端通过验证用户账号密码都正确情况下,通过UUID生成唯一id作为token,再将token作为key、用户信息对象作为value存储到Redis,同时将token存储到cookie,维持会话状态。当用户访问接口时,只需从cookie取出对应的token信息,根据token键值从Redis获取用户对象。

3、异常统一处理

通过自定义拦截器的方式,对所有所有异常进行拦截,并进行相应的处理,然后把结果信息返回给客户端处理。

采用@ControllerAdvice+@ExceptionHandler(value=Exception.class)方式。

4、页面缓存 + 对象缓存
  • 页面缓存:

通过在手动渲染得到的html页面缓存到Redis,下次访问相同页面时直接从Redis中获取进行返回,减少服务端处理的压力。

  • 对象缓存:

把相应的热点对象进行缓存到Redis,比如:用户对象、商品对象、订单对象等,利用缓存来减少对数据库的访问,提高系统的响应速度。这里将参与秒杀的商品在项目启动后预热(写入)到Redis中。

5、页面静态化

使用前后端分离技术,用ajax实现异步请求数据,得到数据后再绑定到当前页面。第一次访问后,页面和数据都会缓存到客户端的浏览器,当再次请求相同的页面时会直接从浏览器缓存加载。

6、内存标记 + Redis预减库存 + RabbitMQ异步处理

通过内存标记 + Redis预减库存 + RabbitMQ异步处理下单,最后才会访问数据库,减少对数据库的访问,是系统整体负载达到最高。

//系统启动时会对其初始化,将所有秒杀商品id存入map,库存为0是为true
private Map<Long,Boolean> localOverMap = new HashMap<Long,Boolean>();

//内存标记,减少redis访问
boolean over = localOverMap.get(goodsId);
if(over) {
    return Result.error(CodeMsg.MIAO_SHA_OVER);
}
//redis预减库存
long stock = redisService.decr(GoodsKey.getSeckillGoodsStock, "" + goodsId);//10
if (stock < 0) {
    localOverMap.put(goodsId,true);
    return Result.error(CodeMsg.MIAO_SHA_OVER);
}

//判断是否已经秒杀到了
SeckillOrder order = orderService.getOrderByUserIdGoodsId(user.getId(), goodsId);
if(order != null) {
    return Result.error(CodeMsg.REPEATE_MIAOSHA);
}

//压入消息队列
//入队
SeckillMessage sm = new SeckillMessage();
sm.setUser(user);
sm.setGoodsId(goodsId);
sender.sendSeckillMessage(sm);

1)在用户发起秒杀访问时,先访问本地已经初始化好的map,看当前秒杀商品id的库存是否已售罄,若已售罄,直接返回秒杀结束异常;若库存还有,在执行下面的操作。通过内存标记可以减少对后面步骤中的Redis访问操作,降低Redis的压力,不然每个请求都将访问一次Redis。

2)系统启动时,即将商品和库存数据初始化到redis中(通过实现InitializingBean接口的afterPropertiesSet方法),所有的抢购操作都在Redis中进行处理,通过Redis预减少库存来减少数据库访问。SpringBoot启动后实现自动执行其它业务方法功能

3)通过使用RabbitMQ用异步队列处理下单,实现系统高响应。此处响应客户端后,一般都是抢购成功了,当然不排除例外,此时客户端通过ajax请求轮询访问下单结果接口,直到响应状态成功或者失败。

7、解决超卖

(1)更新的sql语句,只有当库存大于0才能更新库存

update seckill_goods set stock_count = stock_count-1 where goods_id = #{goodsId} and stock_count > 0

(2)对用户id和商品id建立一个唯一索引,通过这种约束避免同一用户发同时两个请求秒杀到两件相同商品

图片

(3)实现乐观锁,给商品信息表增加一个version字段,为每一条数据加上版本。每次更新的时候version+1,并且更新时候带上版本号,当提交前版本号等于更新前版本号,说明此时没有被其他线程影响到,正常更新,如果冲突了则不会进行提交更新。当库存是足够的情况下发生乐观锁冲突就进行一定次数的重试。

8、接口限流

通过记录用户在某一时间内访问的次数进行拒绝。

自定义AccessLimit接口,在controller方法上添加。

/**
 * 获取秒杀地址
 * 自定义接口限流:5秒内最多访问5次,并需要为登录状态
 * @param user
 * @param goodsId
 * @return
 */
@AccessLimit(seconds=5, maxCount=5, needLogin=true)
@RequestMapping(value = "/path", method = RequestMethod.GET)
@ResponseBody
public Result<String> getSeckillPath(User user, @RequestParam("goodsId") long goodsId) {
    if (user == null) {
        return Result.error(CodeMsg.USER_NO_LOGIN);
    }
    String path = seckillService.createPath(user, goodsId);
    return Result.success(path);
}

三、效果展示

1、SeckillProject代码结构

图片

2、登录首页

账号15898989898

密码123456

图片

3、秒杀商品列表

图片

4、商品详情

图片

5、点击秒杀后订单详情

图片

图片

6、项目源码下载

https://gitee.com/jike11231/sec-kill-product




程序员追风

专注于分享Java各类学习笔记、面试题以及IT类资讯。

公众号

spring-boot-seckill分布式秒杀系统一个SpringBoot开发的从0到1构建的分布式秒杀系统,项目案例基本成型,逐步完善中。 开发环境: JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0 启动说明: 1、启动前 请配置application.properties中相关redis、zk以及kafka相关地址,建议在Linux下安装使用。 2、数据库脚本位于 src/main/resource/sql 下面,启动前请自行导入。 3、配置完成,运行Application中的main方法,访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。 4、秒杀商品页:http://localhost:8080/seckill/index.shtml ,部分功能待完成。 5、本测试案例单纯为了学习,某些案例并不适用于生产环境,大家根据所需自行调整。 秒杀架构: 架构层级 1、一般商家在做活动的时候,经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源),导致真正的我们无法获得服务!所以说高防IP还是很有必要的。 2、搞活动就意味着人多,接入SLB,对多台云服务器进行流量分发,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 3、基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发,来保障后端服务的正常运行。 4、后端秒杀业务逻辑,基于Redis 或者 Zookeeper 分布式锁,Kafka 或者 Redis 做消息队列,DRDS数据库中间件实现数据的读写分离。 优化思路 1、分流、分流、分流,重要的事情说三遍,再牛逼的机器也抵挡不住高级别的并发。 2、限流、限流、限流,毕竟秒杀商品有限,防刷的前提下没有绝对的公平,根据每个服务的负载能力,设定流量极限。 3、缓存、缓存、缓存、尽量不要让大量请求穿透到DB层,活动开始前商品信息可以推送至分布式缓存。 4、异步、异步、异步,分析并识别出可以异步处理的逻辑,比如日志,缩短系统响应时间。 5、主备、主备、主备,如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。 6、最后,为了支撑更高的并发,追求更好的性能,可以对服务器的部署模型进行优化,部分请求走正常的秒杀流程,部分请求直接返回秒杀失败,缺点是开发部署时需要维护两套逻辑。 分层优化 1、前端优化:活动开始前生成静态商品页面推送缓存和CDN,静态文件(JS/CSS)请求推送至文件服务器和CDN。 2、网络优化:如果是全国用户,最好是BGP多线机房,减少网络延迟。 3、应用服务优化:Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值