这是个人第 65 篇原创文章前端
做者 | 悟空聊架构面试
来源 | 悟空聊架构（ID：PassJava666）数据库
转载请联系受权（微信ID：PassJava）编程
星球简介
地点：β-410 星系，A-731电商星球。小程序
时间：新纪元 2036 年。后端
星球简介：缓存
-
中文名：A-731电商星球服务器
-
外文名：A-731 Mall微信
-
分类：行星网络
-
公转周期：一年
-
常驻用户：中间件工做者、各类请求。
-
星球总历史：二十万年。
星球危机
我是一个秒杀请求，天天的工做就是将秒杀请求的数据运送给后端工做者。
这天我在 Nginx 转发服务器上碰见了请求「小空」 ，我跟小空说有重要消息不方便如今告诉他，下班再约，而后就都匆匆赶路了。
我和小空晚上十点下班后来到一家酒吧，点了两杯 mojito，找了一个角落坐下。
小空：你最近看起来心事重重。
我：你有没有发现最近咱们星球的订单数急剧增长，天天有一千万订单数据产生，也不是一天、两天的事了。
小空：难怪我天天加班到晚上十点来运送请求数据。
我：我有个舅舅在航天局上班，告诉我说咱们星球承载不了那么多请求和订单数据，不久就会出现「行星大爆炸」 。你可不要透露给别人。
小空：那怎么办？
我：咱们能够去 100 光年外的 T-714 星球，可是只能经过秒杀通道坐时空穿梭机去那颗星球。并且名额有限制，不知道我有没有机会登上穿梭机。
我：明天通道会开启两次，上午十点和下午两点。你明天和我一块儿去吧！
小空：好的。
星球大爆炸
「涉及的知识点：」
-
这里的行星大爆炸指的是什么？
-
因订单数据量很大，数据库撑不住了。数据库可能宕机。
-
因天天有大量请求发送到服务器，服务器也扛不住了。服务器可能宕机。
-
-
秒杀通道天天开启两次表明了什么？
-
「流量错峰」 ，将流量分摊到两个秒杀场次。
-
固然 「流量错峰」 的手段还有输入验证、加入购物车等分摊流量的作法。
-
秒杀通道
地点：A-731 星球机场
时间：09 : 45
通道
“请前往 T-714 星球的请求旅客到 Y1 站台排队等待进入特殊通道， 15 分钟后开始进入穿梭机大厅”。大厅的广播连续播放了三遍。
我走向了特殊通道，看到通道旁立着一个牌子：秒杀通道，只给秒杀请求使用。
「涉及知识点：」
-
秒杀场景为何 单独弄了条通道？
-
秒杀业务为了避免影响系统的其余业务单独部署了一套秒杀系统。
-
总结为 「服务单一职责 + 独立部署」
-
实时大屏
一抬头看到通道上方有一个大屏，在不断播放 T-714 星球的照片，以及机票的订单信息。
T-714 星球
有两个穿制服的工做者正在大屏旁巡逻。一个制服上印着 Nginx，一个制服上印着 CDN。
Nginx+CDN
「涉及知识点：」
-
Nginx 制服：
-
穿 Nginx 制服的工做者在维护 Nginx 的静态和动态资源。
-
商品详情页是一个静态页面，将这些静态页面存储到 Nginx 服务器上，访问静态资源时，请求先到 Nginx，而后 Nginx 服务器经过请求的 URL 连接来匹配是不是访问的静态资源。
-
大屏的商品详情页并非经过发送请求从后台服务器拿到的。其实实现了 「动静分离」 。
-
-
一张图解释 Nginx 动静分离
Nginx 流程图
-
静态资源好比 HTML 文件极少变化，就能够专门放到一台服务器上，直接访问，不须要与后台服务器交互（好比 Tomcat）。
-
动态资源好比须要从后台拿到有多少人购买了商品，发送下单请求来存储数据，这些都称做动态资源，不能狭隘的理解为看得见的资源，广义上能够包括获取逻辑处理的结果，执行存储数据等操做。
-
-
CDN 制服
-
什么是 CDN：CDN 大白话解释就是用户就近获取资源，减小网络传输时间，提升访问速度。
-
Nginx 上放 HTML文件，而 CDN 上则放 HTML 引入的图片文件、脚本文件。
-
穿 CDN 制服的工做者在维护 CDN 的资源。
-
-
一张流程图解释 CDN 工做原理
CDN 流程图
验证通道
时间：10:00
“验证通道已开启，请携带密码进入！” 又是播放了三遍广播。
输入密码
「涉及的知识点：」
-
为何须要密码？
-
为了防止大量模拟的秒杀请求进入业务处理流程，因此先加一道验证，丢弃这些假请求。
-
怎么作到的？前端网页先发送请求拿到密码，点击抢购时，请求体中携带加密密码，后端校验密码是否匹配。能够经过 MD5 加密。
-
-
总结为 「秒杀请求加密」 。
穿梭机大厅
穿梭机大厅
通过验证通道的筛选后，有一半的假请求被挡在门外，像我这种拿到了正确密码的顺利进入了穿梭机大厅。
来到大厅，发现大厅的正中央摆放着一个显示器，上面显示的红色数字 100 赫然映入眼中。
显示屏的左手边站着一位穿着 Redis 统一制服的靓女。在一旁的我偷听到原来她是控制显示器显示穿梭机剩余数量的。若是数字变为 0 ，则表示穿梭机已经所有被占用，后来的人就得无功而返了。
Redis
「涉及的知识点：」
-
秒杀场景中，查询剩余库存并非直接查数据库，而是查 Redis 缓存的。
-
为何是查缓存？由于查缓存的速度要远远快于查数据库，减小了响应时间，并且对数据库的压力减少了不少。若是不少查库存的请求都到数据库了，那数据库就要崩了，并且数据库干不了其余的活了。
抢票
显示屏的右手边站着一位西装笔挺的年轻帅哥，看到他的袖口上挂着一个红袖章，印着 Redisson 字样。他一脸严肃的模样，对大厅内黑压压一片的请求熟视无睹。多是见惯了这种场景吧。
正在打量这位帅哥时，发现他的左手拿着一叠机票，没错，有了一张机票就能够登入穿梭机了。我以百米冲速的速度到达了他面前，到达他面前时，已经有十几个请求也到了他身边，他按照先来后到的顺序依次发放机票，到个人时候，机票已经只剩几张了，庆幸的是个人百米冲速帮我抢到了一张机票。我问帅哥是否能够再发一张票给我，他拒绝了。
每一次发放票，穿 Redis 制服的靓女都会操做显示屏，让其数量减一。
十秒钟后，票已经发完，显示屏显示数字 0 。
「涉及的知识点：」
-
Redisson 是啥呢？Redis 客户端，解决了分布式的一些常见问题。
-
这里其实用到了 Redisson 的信号量功能，总共有 100 张票，也就是 100 个信号量，并且票的数量不会由于多线程并发或分布式系统的缘由而致使票的数量被超卖。好比卖出了 101 张票。
-
每一个人只能得到一张票，这就是秒杀系统中涉及到的幂等性校验，不能重复抢票。
售票窗口
登机牌
登机牌
发放机票的帅哥告诉我，拿到票后，到 A 窗口排队付款，才能拿到登记牌。因而我和另外 99 个请求一块儿在 A 窗口排队了。
看到一个请求想要放弃付款了，说是机票太贵了，而后准备离开大厅时，被发放机票的帅哥拦住了，他问请求是否要考虑下，有 15 分钟的考虑时间，若是请求仍是以为不行，能够将机票还给他，他能够再发放给其余人。
队列削峰
「涉及的知识点：」
-
秒杀系统中经常使用的「队列削峰」 。秒杀成功的请求，进入队列，慢慢建立订单、扣减库存。
-
秒杀成功后，快速告诉用户已经秒杀成功，而不是等待订单完再告诉用户，那用户就要多等一会了，影响体验。
-
为何要作队列削峰？成功的请求没必要一会儿都去数据库建立订单，这样对数据库的压力也会小一些。
-
在秒杀场景中，颇有可能有用户抢到了可是不付款的场景，这个时候库存是要加回去的，能够提供给其余用户。
启航
订单建立成功后，我顺利拿到了登机牌，经过了登机牌的校验后，成功登上了穿梭机。
出发，去往 T-714 星球。据说那个星球的数据库进行了分库分表、服务也拆分红了微服务。
启航
总结
上面经过科幻小说的方式来说解了秒杀系统中关注的点，下面是对秒杀系统关注的八大点的一个总结：
秒杀场景关注点
-
服务单一职责、独立部署
-
库存预热、快速扣减
-
秒杀连接加密
-
动静分离
-
恶意请求拦截
-
流量错峰
-
限流&熔断&降级
-
队列削峰
只讲原理好像不得劲，是否是要来篇实站？
- END -
你好，我是
悟空哥，「7年项目开发经验，全栈工程师，开发组长，超喜欢图解编程底层原理」。我还手写了2个小程序，Java刷题小程序，PMP刷题小程序，点击个人公众号菜单打开！另外有111本架构师资料以及1000道Java面试题，都整理成了PDF，能够关注公众号 「悟空聊架构」 回复悟空领取优质资料。
「转发->在看->点赞->收藏->评论！！！」 是对我最大的支持！
我是悟空，努力变身超级赛亚人！咱们下期见！
点亮，服务器三年不宕机
本文分享自微信公众号 - 悟空聊架构（PassJava666）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。