本文转载自微信公众号《Java教程》，作者九灵。转载本文请联系Java教程公众号。Java核心技术、分布式架构原理、中间件应用与原理等优质原创文章每日分享概览。致力于帮助更多的孩子加入大厂！今天想和大家聊聊削峰填谷。最近B站机房停电，A站服务雪崩，让我们开始关注高可用。三剑客可以用来限流、熔断和降级。今天想继续讲削峰填谷，也为后面的高性能文章做铺垫。想回顾一下之前相关内容的童鞋们。你可以检查一下。以下文章欢迎点赞、收藏、关注三联，谢谢！高可用系列文章：《面试补习》-什么是限流？Sentinel，限流神器，你不知道吗？阿里P7老大带你解密Sentinel《面试补习》-fusing降级我学会了！削峰填谷技术源于生活。削峰填谷是一种调整用电负荷的措施。根据不同用户的用电规律，合理、有计划地安排组织各类用户的用电时间。减少负载峰值并填充负载低谷。降低电网负荷峰谷差，使发电与用电趋于平衡。在我们对削峰填谷的流量趋势图的理解中，如下图所示，在流量高峰期截断了高峰流量，在流量下降的时候填充这部分流量，这样流量趋于平衡。简述、削峰填谷Peakshaving：为保证服务可用性，去除部分流量。--业务亏损和填谷：在服务能力过剩的情况下，提供补偿操作。--业务补偿调峰，切断流量尖峰，使请求流量趋于稳定，保障服务稳定。客户端调峰和服务端调峰上面说了，调峰是一种破坏业务的行为。流量的减少可能会导致我们在电子商务系统中失去这个用户。1、client的调峰是在后台思考，调峰动作更多的是server端同学的工作和思考。但是在整个系统的设计中，客户端的削峰也是必不可少的。通过客户端的调峰，可以降低服务器的压力，从而保证系统的可用性。1.1.资源动静分离的方案比较简单，还是目前基本采用的方法。通过将静态资源与服务器隔离，并在活动开始前将资源预热到CDN，减轻服务器的压力。客户端与服务器的交互只是动态数据的交互。1.2.请求削峰1)、设置两次请求之间的最小有效时间间隔，设置两次请求之间的时间间隔为t，每个请求间隔内的请求将被忽略，不会向服务发起任何请求，假设在t秒内，每个用户只会触发一次有效请求，对应的qps为1/t。如果用户数为Q，则最大qps为Q/t。2）公平策略每个用户在一个活动周期内的有效请求概率为P，例如概率为0.2，即5次请求机会1次，或者10次请求机会2次。基于随机算法+插值算法生成请求序列：根据上述方法可以得到公平策略，粒度可以自由控制。终端限流主要包括网关限流容器限流服务器限流。在服务器限流中，主要介绍了使用Sentinel进行流量控制。从下面的流程图可以看出，流量控制在2qps，峰值流量以fail-fast的方式通过Return。那么，对于这部分被拒绝的流量，从业务的角度来说，是有损的。2.2.MQ调峰在消息队列的框架中，有拉取和推送两种消息同步方式。我们可以通过下游系统订单系统主动拉取pull方式，保证下游服务的流量稳定。那么，能否摆脱限流，只使用MQ来实现调峰呢？答案是不！假设秒杀系统的流量为：10000qps，订单系统的消费能力只有100qps。如果活动时间持续时间过长，就会积累过多的消息。一方面会对消息中间件造成压力，另一方面也没有办法保证消息的有效性。因此，在这个链路图中，实际场景会是这样的：先经过Sentinel等限流中间件拉平流量后，再由秒杀系统提交MQ任务。填谷从上面的调峰策略可以看出，从客户端发起的请求限流到服务端的中间件限流，大部分的调峰都是业务丢包。对于这部分请求，直接丢弃。在MQ调峰场景下，我们可以通过缓冲请求来减缓流量压力，同时有下游服务来控制请求压力，从而达到调峰的效果。没有调峰，就没有填谷。在MQ调峰场景中，我们主要保证订单系统的流量稳定性。如果秒杀系统的消息流量是100tps，订单系统的处理能力是200tps，那么，对于下游系统来说，是没有峰值流量的！如有其他情况，可交换修正填谷补偿。在高峰流量阶段，部分流量无法立即处理。高峰流量过去后，在消费能力过剩的情况下，对之前的请求进行补偿操作，使得整体流量趋于稳定。比如上面的链接图中，秒杀活动持续了1分钟，产生的请求数为：60*100=6000个请求。消耗时间为：6000/50=120秒。在用户可接受的范围内（等待1分钟），获取自己闪购订单的结果。同时保护订单系统的负载。消息队列的风险相对于其他调峰方案，似乎MQ调峰方案是最好的，那为什么我们在流量控制方案中更关注限流方案。而不是统一使用MQ削峰？每种解决方案都有优点和缺点。MQ的引入可以为我们解决削峰、异步、解耦等问题。但是引入MQ中间件，也会给我们带来以下问题：中间件可用性：MQ队列不可用，会导致整个链路不可用，严重的会造成雪崩消息可靠性：消息发送，消费需要保证消息堆积：消息生产过快，导致MQ中间件压力过大消息重复：消费幂等支持消息顺序：部分场景需要消费按顺序执行
