SpringBoot开发案例从0到1构建分布式秒杀系统

最新推荐文章于 2024-06-03 19:13:30 发布

baoba84620

最新推荐文章于 2024-06-03 19:13:30 发布

阅读量220

点赞数

文章标签： java 大数据数据库

原文链接：http://www.cnblogs.com/xianhenyuan/p/11085178.html

版权

声明：转载文章，为防止丢失所以做此备份。
原文地址：https://blog.52itstyle.vip/archives/2853/

最近，被推送了不少秒杀架构的文章，忙里偷闲自己也总结了一下互联网平台秒杀架构设计，当然也借鉴了不少同学的思路。俗话说，脱离案例讲架构都是耍流氓，最终使用SpringBoot模拟实现了部分秒杀场景，同时跟大家分享交流一下。

秒杀场景无非就是多个用户在同时抢购一件或者多件商品，专用词汇就是所谓的高并发。现实中经常被大家喜闻乐见的场景，一群大妈抢购打折鸡蛋的画面一定不会陌生，如此场面让服务员大姐很无奈，赶上不要钱了。

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

在这里插入图片描述

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

优化思路

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