springboot 秒杀系统(一)

秒杀系统应该是很检验一个人的能力的项目。包括从前端

到运营商到nginx到后端等等,很多地方可以优化。

前端的页面控制,运营商的CDN加速,nginx的动静分离等

下面我来一步一步实现后端的秒杀功能的一步一步实现和优化。

后端接口

1,获取商品详情,2,秒杀接口

获取商品:参数 商品ID        通过商品ID返回商品详情。

秒杀接口:参数 商品ID        后端接收商品ID,判断是否有库存,

          没有:返回已售完   

          有:库存-1,创建订单,返回秒杀成功

测试工具   jmeter  测试这2个接口的QPS(每秒处理请求数)

期望结果: 商品能够正常秒杀,不能出现超卖等异常,QPS越高越好。

1.0版本: 不借用其他中间件和优化,正常的操作数据库。实现功能

/**
     * 秒杀一般只限购1个,所以数量都是1
     * @return 1 成功 0 失败
     */
    public int secKill(String seckillId,String userid){
        /**
         * 第一步:判断当前时间是否在秒杀时间段内
         * 第二步:判断是否有库存:有  库存减一  没有直接返回售完
         * 第三步:创建订单,返回成功
         */
        //判断当前时间是否在秒杀时间段内
        JSONObject jsonObject = productService.findById(seckillId);
        if(jsonObject==null){
            return 0;
        }
        if(judgeTime(jsonObject.getTimestamp("starttime"),jsonObject.getTimestamp("endtime"))){
            return 0;
        }
        //更新库存减一,成功返回1,失败返回0
        int isSelfOut = productDao.updataNumById(seckillId);
        if(isSelfOut==0) {
            return 0;
        }
        //创建订单
        orderDao.createOrder(seckillId,userid);
        return 1;
    }

    /**
     * 如果当前时间在秒杀时间端,返回false,不在返回true
     * @param starttime
     * @param endtime
     * @return
     */
    private boolean judgeTime(Timestamp starttime, Timestamp endtime) {
        Date date = new Date();
        return !(date.getTime()>starttime.getTime()&&date.getTime()<endtime.getTime());
    }

判断是否有库存,有 减一 SQL<!-- 这里做判断是否有库存和数量减一操作,
如果库存大于1,则 更新记录返回 1
如果库存等于,更新失败,返回 0
所以是不会出现超卖的现象-->
<update id="updataNumById">
update seckill set inventory=inventory-1
where seckillId=#{seckillId} and inventory>0
</update>

 

秒杀商品表 :ID,商品名,库存数,开始时间,结束时间:

测试计划jmeter并发1000。获取商品传入商品ID,秒杀接口传入商品ID和随机11位用户ID

测试结果:  如下图,商品接口 qps 110   秒杀 qps 68,这个跟电脑配置有关。

订单表500表记录,商品表1000的库存变为0,没有出现超卖现象,逻辑正常,数据一致性

第一个版本是正常的没有借用其他组件的,下个博客在此基础上一步步优化。

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、付费专栏及课程。

余额充值