网站由哪三部分组成,电商网站运营建设的目标,做食品那些网站,网上商城网站开发报告流量削峰的由来 主要是还是来自于互联网的业务场景#xff0c;例如#xff0c;马上即将开始的春节火车票抢购#xff0c;大量的用户需要同一时间去抢购#xff1b;以及大家熟知的阿里双11秒杀#xff0c; 短时间上亿的用户涌入#xff0c;瞬间流量巨大#xff08;高并发… 流量削峰的由来 主要是还是来自于互联网的业务场景例如马上即将开始的春节火车票抢购大量的用户需要同一时间去抢购以及大家熟知的阿里双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等消息队列在一端承接瞬时的流量洪峰在另一端平滑地将消息推送出去。 你可能也喜欢: 消息中间件系列(八)Kafka、RocketMQ、RabbitMQ等的优劣势比较消息中间件系列(四)消息队列MQ的特点、选型、及应用场景详解消息中间件系列三主流的消息队列中间件有哪些 消息中间件系列(五)MQ消息队列的12点核心原理总结消息中间件系列(七)如何从0到1设计一个消息队列中间件消息中间件系列一消息中间件介绍、典型使用场景、以及使用原则
