我要手把手教你搭建一套抗瞬时百万流量的秒杀系统

Posted 2023-04-25 冰河

作者：冰河
星球：http://m6z.cn/6aeFbs
博客：https://binghe.gitcode.host
文章汇总：https://binghe.gitcode.host/md/all/all.html
源码获取地址：https://t.zsxq.com/0dhvFs5oR

沉淀，成长，突破，帮助他人，成就自我。

大家好，我是冰河~~

今天，正式通知大家一件事情：在今后一段时间内，冰河会带着大家一起从零开始搭建并开发一套可支持瞬时百万流量的高并发秒杀系统，这里会涉及到很多互联网大厂开发过程中所使用的核心技术和架构设计模式，也有冰河在大厂工作过程中，自主研发和参与研发的企业级中间件技术。

在《Seckill秒杀系统》专栏中，你学到的不仅仅是一套支持瞬时百万流量的高并发、高性能、高可用、可扩展的秒杀系统，更重要的是要学会大厂处理高并发、大流量场景的技术方案和架构设计思想，并学会如何将这些技术方案和架构设计思想落地到实际项目中。

一、秒杀专栏背景调研

相信很多小伙伴学习了不少关于并发编程相关的基础知识，同时，不少小伙伴也看了冰河出版的《深入理解高并发编程：核心原理与案例实战》与《深入理解高并发编程：JDK核心技术》图书。当然，后续根据实际情况，可能会出版《深入理解高并发编程》系列的其他书籍。但是很多小伙伴在和冰河交流的过程中，普遍存在如下几个问题：

• 一直在小公司做CRUD，并发编程没接触过，更别提如何高并发实际项目了。
• 公司项目没什么并发，在线人数也不多，学了很多并发编程相关的知识不知道怎么用。
• 学了很多并发编程的知识，也知道一些概念，能说出一些简单的方案，但是没实际项目经验。
• 自我感觉掌握了一些高并发编程的技术方案，但是如果真正做项目时，还是不知道如何下手。
• 简历上写了熟悉并发编程，在面试过程中，面试官一般会问秒杀系统，或者其他高并发项目实战问题，不知道怎么回答。
• 在大厂工作多年，参与了一些系统的建设与研发，但是也没机会参与像秒杀系统这样高并发、大流量的系统的整个建设过程。
• 其他问题。。。

可以看到，从收集的这些并发编程相关的问题来看，存在的问题是普遍性的：小公司的小伙伴受限于业务，接触不到高并发、大流量的业务场景，大厂的小伙伴由于某些原因没有被分到高并发、大流量业务部门。但更多的是大体掌握了并发编程的基础知识，而没有系统性落地成实际高并发项目的经验。

为了彻底解决小伙伴们的困惑，也为了进一步突破大家的技术瓶颈，冰河带着他的《Seckill秒杀系统》来了，在这里，你学到的不仅仅是一套支持瞬时百万流量的高并发、高性能、高可用、可扩展的秒杀系统，更重要的是要学会大厂处理高并发、大流量场景的技术方案和架构设计思想，并学会如何将这些技术方案和架构设计思想落地到实际项目中。。

二、为何要搞秒杀系统

说起秒杀系统，我相信学习这个专栏的你一定对秒杀系统有所了解，甚至多多少少也参与了秒杀活动。为啥？因为国内头部电商平台每年的618、双11都会举行大促活动，相信你是参与过的，最起码你可能为这些活动贡献了流量。而每年的618、双11最直观的体现就是流量和交易额。

这些最直观的数字背后，却需要很多高并发编程的知识和技术作为支撑。作为程序员，或者说互联网技术人，尤其是了解一些并发编程技术和方案的开发者，一定对每年618、双11大促背后的技术感兴趣。

单就秒杀系统本身而言，它是高并发、大流量场景下最具代表性的系统，如果你连秒杀系统的各项技术细节都了然于胸了，那其他涉及到并发的系统对你来说，还叫个事儿吗？另外，秒杀系统背后涉及到的高并发、高性能、高可用、可扩展的技术思路和架构模式与架构思想，你可以直接复用于任何需要支撑高并发、大流量的业务场景。

另外，一般只有互联网大厂才具备真正研发秒杀系统的业务场景，所以，这次《Seckill秒杀系统》专栏也是一次贴近大厂真实项目的机会，专栏中涉及到的架构模式和技术点都是大厂在研发秒杀系统过程中真正实践和优化过的架构模式与技术点，认真学习《Seckill秒杀系统》专栏，认真消化吸收专栏中的每项知识点、技术思路和架构模式，并亲自动手实践每个并发编程的技巧和方案，相信你会有非常多的收获，而这些收获是实实在在的，也是互联网大厂经常使用的核心技术。

三、秒杀系统核心技术

单就秒杀系统本身而言，就是为应对瞬时高并发、大流量场景而设计的支持高并发、大流量的系统，其背后会涉及到众多高并发、高性能、高可用的技术作为基础保障。同时，在系统中，也要重点突破库存与限购、防刷与风控、数据一致、热点隔离、动静分离、削峰填谷、数据兜底、限流与降级、流控与容灾等核心技术问题。

所以，冰河总结了秒杀系统所涉及到的最核心的技术内容，整理后如下图所示。

由图也可以看出，《Seckill秒杀系统》专栏一定不会让你失望，它能够将真正的高并发编程知识串起来，形成知识面，并将这些高并发编程知识落地成秒杀系统，而在开发秒杀系统的过程中所使用到的技术，是互联网大厂真正在使用的核心技术。

注意：《Seckill秒杀系统》专栏会大量使用到冰河出版的《深入理解高并发编程：核心原理与案例实战》与《深入理解高并发编程：JDK核心技术》图书中的知识，建议学习《Seckill秒杀系统》专栏的过程中，阅读《深入理解高并发编程：核心原理与案例实战》与《深入理解高并发编程：JDK核心技术》图书。

四、如何学习秒杀系统

1.加入 冰河技术 知识星球，才能查看星球专栏文章，查看置顶消息，申请加入项目，才能看到项目代码和技术小册，如果未申请加入项目，点击项目链接，你会发现是404页面。

2.专栏的每一章会对应一个代码分支，需要切换对应的分支学习对应的文章的代码分支，同时，分支中的doc/assets/sql里是当前分支的最新SQL语句，在对应的分支查看SQL，更新到自己的数据库中即可。

3.学习过程中最好按照章节顺序来学习，每一章前后都是比较连贯的，并且每一章的代码实现也有先后顺序，这样按照从前往后的顺序学习，最终你会实现一个完整的秒杀系统。

注意：学习的过程，不是复制粘贴代码的过程，赋值粘贴代码是没有任何意义的，最好的学习方式就是自己动手实现代码，然后思考、总结。

4.代码结构：master分支是最新的全量代码，专栏中每一章都会对应一个代码分支，切换到章节对应的代码分支后，即可根据当前章节学习对应的代码实现，不然，在master分支中看到的是全量的代码。

5.对应代码实现上的问题，可以在专栏对应的源码提issuse：https://gitcode.net/binghe001/seckill/-/issues。

6.冰河后续会为《Seckill秒杀系统》专栏录制完整的视频课程。

五、提交作业

在学习秒杀系统的过程中，为了有助于大家更好的消化吸收《Seckill秒杀系统》的知识，冰河会为大家布置相应的作业。当然，也是为了希望在学习的过程中，留下你真实的足迹，让我们一起努力，突破自身技术瓶颈。

1.代码作业

• 作业空间：https://gitcode.net/seckillteam
• 空间说明：为知识星球的用户提供项目代码提交空间，方便针对项目进行技术交流，你可以把自己实现的《Seckill秒杀系统》源码提交到空间中，按照 项目名称-用户星球编号-作者名称 的格式创建仓库，例如 seckill-1-binghe。

2.文字打卡

• 大家可以在 冰河技术 知识星球中，提交文字作业也可以进行文字打卡，也可以到链接 https://gitcode.net/binghe001/seckill/-/issues 提交issues。

主要按照如下方式进行总结：

1.今天你学了哪些章节？
2.遇到的问题是什么？
3.你是怎么解决问题的？
4.今天的收获是什么？

基于大家的打卡或者作业反馈的问题，冰河会在后续以文章和直播的形式统一解决大家学习过程中的疑问。

写在最后

对项目不太了解的小伙伴也可以到github：https://github.com/binghe001/distribute-seckill 进行了解，冰河会整理部分源码和说明到github，欢迎各位小伙伴一起交流，一起学习，一起进步，在技术的道路上一起探索，收获满满~~

好了，今天就到这儿吧，我是冰河，我们下期见~~

秒杀/抢购系统设计优化

12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存，读写冲突，锁非常严重；
小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万；
这是秒杀业务难的地方。那我们怎么优化秒杀系统呢？

一、难点

（1）高并发
用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。
（2）超卖
由于库存并发更新的问题，导致在实际库存已经不足的情况下，库存依然在减，导致卖家的商品卖得件数超过秒杀的预期。

二、架构

常见的站点架构基本是这样的:
（1）浏览器端，最上层，会执行到一些JS代码
（2）站点层，这一层会访问后端数据，拼HTML页面返回给浏览器
（3）服务层，向上游屏蔽底层数据细节，提供数据访问
（4）数据层，最终的库存是存在这里的

三、思路

（1）将请求尽量拦截在上游：传统秒杀系统之所以挂，请求都压倒了后端数据层，数据库读写锁冲突严重，导致响应慢，下单基本不能成功
（2）利用缓存：这是一个典型的读多写少的应用场景，非常适合使用缓存

四、解决方案

（1）浏览器层请求拦截
1.产品层面，用户点击“查询”或“购票”后，按钮置灰，禁止用户重复提交请求
2.js层面，限制用户在n秒之内只能提交一次请求
（2）站点层请求拦截与页面缓存
1.静态化，将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素
2.限频率，同一个UID，限制访问频率，做页面缓存，n秒内到达站点层的请求，均返回同一页面
（3）服务层请求拦截与数据缓存
1.对于写请求，将所有写请求在缓存（Redis或Memcached）中，做请求单队列排队，每次只透过有限的写请求异步写入到数据层，如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”
2.对于读请求，用Redis或Memcached
缓存写性能和读性能都远高于MySQL，只有非常少的写和读缓存的请求会透到数据层去
（4）数据层
1.尝试扣减库存，扣减库存成功才会进行下单逻辑（由于MySQL事务的特性，不可能完全避免超卖）

UPDATE table_name SET n=n-1 WHERE n>1;

2.扣减库存后进行检查，保证减完不能等于负数
查看更多：
开发一个微信小程序实例教程
HTTP协议整理
PHP安全之Web攻击
MySQL优化
Linux下常见的IO模型
参考资料：
https://my.oschina.net/xianggao/blog/524943
http://www.infoq.com/cn/articles/flash-deal-architecture-optimization