项目介绍

SpringBoot开发案例从0到1构建分布式秒杀系统，项目案例基本成型，逐步完善中。

业务特点

• 瞬间高并发、电脑旁边的小哥哥、小姐姐们如超市哄抢的大妈一般，疯狂的点着鼠标
• 库存少、便宜、稀缺限量，值得大家去抢购，如苹果肾，小米粉，锤子粉(理解万岁)

用户规模

用户规模可大可小，几百或者上千人的活动单体架构足以可以应付，简单的加锁、进程内队列就可以轻松搞定。一旦上升到百万、千万级别的规模就要考虑分布式集群来应对瞬时高并发。

秒杀架构

架构层级

• 一般商家在做活动的时候，经常会遇到各种不怀好意的DDOS攻击(利用无辜的吃瓜群众夺取资源)，导致真正的我们无法获得服务！所以说高防IP还是很有必要的。
• 搞活动就意味着人多，接入SLB，对多台云服务器进行流量分发，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。
• 基于SLB价格以及灵活性考虑后面我们接入Nginx做限流分发，来保障后端服务的正常运行。
• 后端秒杀业务逻辑，基于Redis 或者 Zookeeper 分布式锁，Kafka 或者 Redis 做消息队列，DRDS数据库中间件实现数据的读写分离。

优化思路

• 分流、分流、分流，重要的事情说三遍，再牛逼的机器也抵挡不住高级别的并发。
• 限流、限流、限流，毕竟秒杀商品有限，防刷的前提下没有绝对的公平，根据每个服务的负载能力，设定流量极限。
• 缓存、缓存、缓存、尽量不要让大量请求穿透到DB层，活动开始前商品信息可以推送至分布式缓存。
• 异步、异步、异步，分析并识别出可以异步处理的逻辑，比如日志，缩短系统响应时间。
• 主备、主备、主备，如果有条件做好主备容灾方案也是非常有必要的(参考某年锤子的活动被攻击)。
• 最后，为了支撑更高的并发，追求更好的性能，可以对服务器的部署模型进行优化，部分请求走正常的秒杀流程，部分请求直接返回秒杀失败，缺点是开发部署时需要维护两套逻辑。

分层优化

• 前端优化：活动开始前生成静态商品页面推送缓存和CDN，静态文件(JS/CSS)请求推送至文件服务器和CDN。
• 网络优化：如果是全国用户，最好是BGP多线机房，减少网络延迟。
• 应用服务优化：Nginx最佳配置、Tomcat连接池优化、数据库配置优化、数据库连接池优化。

全链路压测

• 分析需压测业务场景涉及系统
• 协调各个压测系统资源并搭建压测环境
• 压测数据隔离以及监控(响应时间、吞吐量、错误率等数据以图表形式实时显示)
• 压测结果统计(平均响应时间、平均吞吐量等数据以图表形式在测试结束后显示)
• 优化单个系统性能、关联流程以及整个业务流程

整个压测优化过程就是一个不断优化不断改进的过程，事先通过测试不断发现问题，优化系统，避免问题，指定应急方案，才能让系统的稳定性和性能都得到质的提升。

开发环境

JDK1.7、Maven、Mysql、Eclipse、SpringBoot1.5.10、zookeeper3.4.6、kafka_2.11、redis-2.8.4、curator-2.10.0

启动说明

• 启动前 请配置 application.properties 中相关redis、zk以及kafka相关地址，建议在Linux下安装使用。
• 数据库脚本位于 src/main/resource/sql 下面，启动前请自行导入。
• 配置完成，运行Application中的main方法，访问 http://localhost:8080/seckill/swagger-ui.html 进行API测试。
• 秒杀商品页：http://localhost:8080/seckill ，部分功能待完成。
• 本测试案例单纯为了学习，某些案例并不适用于生产环境，大家根据所需自行调整。

测试入口

http://localhost:8080/seckill/swagger-ui.html

项目截图

项目地址

https://gitee.com/52itstyle/spring-boot-seckill