显示屏的左手边站着一位穿着 Redis 统一制服的靓女。在一旁的我偷听到原来她是控制显示器显示穿梭机剩余数量的。如果数字变为 0 ，则表示穿梭机已经全部被占用，后来的人就得无功而返了。
涉及的知识点：
秒杀场景中，查询剩余库存并不是直接查数据库，而是查 Redis 缓存的。
为什么是查缓存？因为查缓存的速度要远远快于查数据库，减少了响应时间，而且对数据库的压力减小了很多。如果很多查库存的请求都到数据库了，那数据库就要崩了，而且数据库干不了其他的活了。
抢票显示屏的右手边站着一位西装笔挺的年轻帅哥，看到他的袖口上挂着一个红袖章，印着 Redisson 字样。他一脸严肃的模样，对大厅内黑压压一片的请求熟视无睹。可能是见惯了这种场景吧。
正在打量这位帅哥时，发现他的左手拿着一叠机票，没错，有了一张机票就可以登入穿梭机了。我以百米冲速的速度到达了他面前，到达他面前时，已经有十几个请求也到了他身边，他按照先来后到的顺序依次发放机票，到我的时候，机票已经只剩几张了，庆幸的是我的百米冲速帮我抢到了一张机票。我问帅哥是否可以再发一张票给我，他拒绝了。
每一次发放票，穿 Redis 制服的靓女都会操作显示屏，让其数量减一。
十秒钟后，票已经发完，显示屏显示数字 0 。
涉及的知识点：
Redisson 是啥呢？Redis 客户端，解决了分布式的一些常见问题。
这里其实用到了 Redisson 的信号量功能，总共有 100 张票，也就是 100 个信号量，而且票的数量不会因为多线程并发或分布式系统的原因而导致票的数量被超卖。比如卖出了 101 张票。
每个人只能获得一张票，这就是秒杀系统中涉及到的幂等性校验，不能重复抢票。
发放机票的帅哥告诉我，拿到票后，到 A 窗口排队付款，才能拿到登记牌。于是我和另外 99 个请求一起在 A 窗口排队了。
看到一个请求想要放弃付款了，说是机票太贵了，然后准备离开大厅时，被发放机票的帅哥拦住了，他问请求是否要考虑下，有 15 分钟的考虑时间，如果请求还是觉得不行，可以将机票还给他，他可以再发放给其他人。
涉及的知识点：
秒杀系统中常用的队列削峰 。秒杀成功的请求，进入队列，慢慢创建订单、扣减库存。
秒杀成功后，快速告诉用户已经秒杀成功，而不是等待订单完在告诉用户，那用户就要多等一会了，影响体验。
为什么要做队列削峰？成功的请求不必一下子都去数据库创建订单，这样对数据库的压力也会小一些。
在秒杀场景中，很有可能有用户抢到了但是不付款的场景，这个时候库存是要加回去的，可以提供给其他用户。
启航订单创建成功后，我顺利拿到了登机牌，通过了登机牌的校验后，成功登上了穿梭机。
出发，去往 T-714 星球。听说那个星球的数据库进行了分库分表、服务也拆分成了微服务。
上面通过科幻小说的方式来讲解了秒杀系统中关注的点，但并没有讲全，所以下面列出了秒杀系统关注的八大点：
服务单一职责、独立部署
库存预热、快速扣减
秒杀链接加密
动静分离
恶意请求拦截
流量错峰
限流&熔断&降级
队列削峰
只讲原理好像不得劲，是不是要来篇实战！