一、开源项目简介
SpringBoot开发案例从0到1构建分布式秒杀系统，项目案例基本成型，适合技术深入研究及实践。
二、功能概述
秒杀场景
秒杀场景无非就是多个用户在同时抢购一件或者多件商品，专用词汇就是所谓的高并发。现实中经常被大家喜闻乐见的场景，一群大妈抢购打折鸡蛋的画面一定不会陌生，如此场面让服务员大姐很无奈，赶上不要钱了。
业务特点
瞬间高并发、电脑旁边的小哥哥、小姐姐们如超市哄抢的大妈一般，疯狂的点着鼠标
库存少、便宜、稀缺限量，值得大家去抢购，如苹果肾，小米粉，锤子粉(理解万岁)
用户规模
用户规模可大可小，几百或者上千人的活动单体架构足以可以应付，简单的加锁、进程内队列就可以轻松搞定。一旦上升到百万、千万级别的规模就要考虑分布式集群来应对瞬时高并发。
通过技术手段，在秒杀场景解决以下问题：
【秒杀】
- 秒杀一(超卖)
最简单的查询更新操作，不涉及各种锁，会出现超卖情况。 - 秒杀二(超卖)
使用ReentrantLock重入锁，由于事物提交和锁释放的先后顺序也会导致超卖。 - 秒杀三(正常)
基于秒杀二场景的修复，锁上移，事物提交后再释放锁，不会超卖。 - 秒杀四(少买)
基于数据库悲观锁实现，查询加锁，然后更新，由于使用了 限流 注解(可自行注释)，这里会出现少买。 - 秒杀五(正常)
基于数据库悲观锁实现，更新加锁并判断剩余数量。 - 秒杀六(正常)
基于数据库乐观锁实现，先查询商品版本号，然后根据版本号更新，判断更新数量。少量用户抢购的时候会出现 少买 的情况。 - 秒杀七(少买)
基于进程内队列 LinkedBlockingQueue 实现，同步消费，由于使用了 限流 注解(可自行注释)，这里会出现少买。如果想正常，去掉startSeckil方法上的@ServiceLimit注解即可。 - 秒杀八(少买)
基于高性能队列 Disruptor实现，同步消费，由于使用了 限流 注解(可自行注释)，这里会出现少买。如果想正常，去掉startSeckil方法上的@ServiceLimit注解即可。
三、技术选型
开发环境
JDK1.8、Maven、MySQL、IntelliJ IDEA、SpringBoot1.5.10、Zookeeper3.4.6、Kafka_2.11、Redis-2.8.4、Curator-2.10.0
技术框架
SpringBoot 2.2.6.RELEASE + ShardingSphere 4.0.1 + MySQL + Druid + Lombok + Swagger
秒杀架构
架构层级
- 一般商家在做活动的时候，经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源)，导致真正的我们无法获得服务！所以说高防IP还是很有必要的。
- 搞活动就意味着人多，接入SLB，对多台云服务器进行流量分发，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。
- 基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发，来保障后端服务的正常运行。
- 后端秒杀业务逻辑，基于Redis 或者 Zookeeper 分布式锁，Kafka 或者 Redis 做消息队列，DRDS数据库中间件实现数据的读写分离。
优化思路
- 分流、分流、分流，重要的事情说三遍，再牛逼的机器也抵挡不住高级别的并发。
- 限流、限流、限流，毕竟秒杀商品有限，防刷的前提下没有绝对的公平，根据每个服务的负载能力，设定流量极限。
- 缓存、缓存、缓存、尽量不要让大量请求穿透到DB层，活动开始前商品信息可以推送至分布式缓存。
- 异步、异步、异步，分析并识别出可以异步处理的逻辑，比如日志，缩短系统响应时间。
- 主备、主备、主备，如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。
- 最后，为了支撑更高的并发，追求更好的性能，可以对服务器的部署模型进行优化，部分请求走正常的秒杀流程，部分请求直接返回秒杀失败，缺点是开发部署时需要维护两套逻辑。
分层优化
- 前端优化：活动开始前生成静态商品页面推送缓存和CDN，静态文件(JS/CSS)请求推送至文件服务器和CDN。
- 网络优化：如果是全国用户，最好是BGP多线机房，减少网络延迟。
- 应用服务优化：Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。
四、界面展示
五、开源协议
使用Apache2.0开源协议
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
评论(0)