高并发架构系列：什么是流量削峰？如何解决秒杀业务的削峰场景

流量削峰的由来

主要是仍是来自于互联网的业务场景，例如，立刻即将开始的春节火车票抢购，大量的用户须要同一时间去抢购；以及你们熟知的阿里双11秒杀， 短期上亿的用户涌入，瞬间流量巨大（高并发），好比：200万人准备在凌晨12:00准备抢购一件商品，可是商品的数量缺是有限的100-500件左右。

这样真实能购买到该件商品的用户也只有几百人左右， 可是从业务上来讲，秒杀活动是但愿更多的人来参与，也就是抢购以前但愿有愈来愈多的人来看购买商品。

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

咱们都知道服务器的处理资源是有限的，因此出现峰值的时候，很容易致使服务器宕机，用户没法访问的状况出现。

这就比如出行的时候存在早高峰和晚高峰的问题，为了解决这个问题，出行就有了错峰限行的解决方案。

同理，在线上的秒杀等业务场景，也须要相似的解决方案，须要平安度过同时抢购带来的流量峰值的问题，这就是流量削峰的由来。

怎样来实现流量削峰方案

削峰从本质上来讲就是更多地延缓用户请求，以及层层过滤用户的访问需求，听从“最后落地到数据库的请求数要尽可能少”的原则。

1.消息队列解决削峰

要对流量进行削峰，最容易想到的解决方案就是用消息队列来缓冲瞬时流量，把同步的直接调用转换成异步的间接推送，中间经过一个队列在一端承接瞬时的流量洪峰，在另外一端平滑地将消息推送出去。

消息队列中间件主要解决应用耦合，异步消息， 流量削锋等问题。经常使用消息队列系统：目前在生产环境，使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等。

在这里，消息队列就像“水库”同样，拦蓄上游的洪水，削减进入下游河道的洪峰流量，从而达到减免洪水灾害的目的。

具体的消息队列MQ选型和应用场景能够参考(点击查看)：高并发架构系列：详解分布式之消息队列的特色、选型、及应用场景

2.流量削峰漏斗：层层削峰

针对秒杀场景还有一种方法，就是对请求进行分层过滤，从而过滤掉一些无效的请求。

分层过滤其实就是采用“漏斗”式设计来处理请求的，以下图所示：

这样就像漏斗同样，尽可能把数据量和请求量一层一层地过滤和减小了。

1）分层过滤的核心思想

• 经过在不一样的层次尽量地过滤掉无效请求。
• 经过CDN过滤掉大量的图片，静态资源的请求。
• 再经过相似Redis这样的分布式缓存，过滤请求等就是典型的在上游拦截读请求。

2）分层过滤的基本原则

• 对写数据进行基于时间的合理分片，过滤掉过时的失效请求。
• 对写请求作限流保护，将超出系统承载能力的请求过滤掉。
• 涉及到的读数据不作强一致性校验，减小由于一致性校验产生瓶颈的问题。
• 对写数据进行强一致性校验，只保留最后有效的数据。

最终，让“漏斗”最末端(数据库)的才是有效请求。例如：当用户真实达到订单和支付的流程，这个是须要数据强一致性的。

总结

1.对于秒杀这样的高并发场景业务，最基本的原则就是将请求拦截在系统上游，下降下游压力。若是不在前端拦截极可能形成数据库(mysql、oracle等)读写锁冲突，甚至致使死锁，最终还有可能出现雪崩等场景。

2.划分好动静资源，静态资源使用CDN进行服务分发。

3.充分利用缓存(redis等)：增长QPS，从而加大整个集群的吞吐量。

4.高峰值流量是压垮系统很重要的缘由，因此须要Kafka等消息队列在一端承接瞬时的流量洪峰，在另外一端平滑地将消息推送出去。

---

原文连接