秒杀系统----流量削峰如何处理？

前言：探讨一些流量削峰的由来？

还是举例来说吧：马上即将开始的春节火车票抢购，大量的用户需要同一时间去抢购；以及大家熟知的阿里双11秒杀。

短时间上亿的用户涌入，瞬间流量巨大（高并发），比如：200万人准备在凌晨12:00准备抢购一件商品，但是商品的数量缺是有限的100-500件左右。

不管多少的访问量，最终抢到的商品的人也就100-500。 但是从业务上来说，秒杀活动是希望更多的人来参与，也就是抢购之前希望有越来越多的人来看购买商品。

但是，在抢购时间达到后，用户开始真正下单时，秒杀的服务器后端不希望同时有几百万人同时发起抢购请求。

我们都知道服务器的处理资源是有限的，所以出现峰值的时候，很容易导致服务器宕机，用户无法访问的情况出现。

---

2.削峰的目的？

• 减少、过滤掉一些无用的请求，节省服务器资源

---

3.操作思路？

• 无损（不会损失用户的发出请求）采用 ：排队、答题、分层过滤等实现方案

• 有损方案，例如：限流、机器负载等强制性措施

---

排队

1，使用消息队列来缓冲瞬时高流量,使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等
2，线程池加锁等待也是常用的一种排队方式
3，先进先出，先进后出等常用的内存排队算法实现方式。
4，把请求序列化到文件中，然后再顺序的读文件（例如基于mysql二进制文件同步机制）来回复请求等方式

答题

题库系统：生成问题和答案。（问题和答案均以key的形式，通过MD5加密）保存在redis？推送到CDN
推送系统：把题目推送给详情系统和交易系统，保证题目的唯一性，防止用户作弊。（答题时间设置1s以上）
图片题目系统：它题目生成图片，包含噪点，防止机器答题。而且答题时比较拥挤，所以要提前把题目上传到cdn进行预热，不然等用户请求时，图片加载可能比较慢，影响答题体验。

过滤

分层过滤:像漏斗型，使得最后的请求是最有用的。
CDN过滤：大部分的数据和流量在用户浏览器或者CDN上获取，这一层可拦截大量数据的读取
前台系统过滤（详情系统）尽量走cache，过滤调掉一部分无用数据
后台系统过滤（交易系统）对上一步骤的极致校验，对系统做好保护和限流，数据量和请求就进一步减少了。
数据库过滤：保证数据的一致性。

---

总结：

队列缓冲方式：更加通用，适用于内部上下游系统之间调用请求不平缓的场景。内部系统的服务质量要求不能随意丢弃请求，所以使用消息队列能起到很好缓冲的作用。

答题缓冲方式：更使合营销或秒杀场景，当用户在发起请求的那一刻就开始缓冲，控制速度，和后面的分层过滤搭配使用效果更佳。

分层过滤方式：主要用在交易的写请求，既阻塞了一些无用数据，也保证了数据强一致性。（例如：减库存或拼车的场景，在读的时候，数据一直在变化，是否有库存或者有空位的情况，评估的正确性保证不了，刚好写数据的时候过滤一部分）

也可以采取一些技术操作：例如：在0点开始抢购之前，发放一些优惠券，抽奖活动等方式，分流，减轻流量削峰带来的压力。

---

可参考：https://blog.csdn.net/u014231523/article/details/83005788