《高可用系列》--来聊聊削峰填谷！
概述
今天想和大家聊聊削峰填谷，最近 B 站发生的机房断电事件，和A站的服务雪崩，让我们对高可用关注了起来，之前梳理了高可用三剑客 限流，熔断和降级，今天想继续聊聊削峰填谷,也为后面的高性能篇 做一下铺垫， 想回顾一下之前相关内容的童鞋,可以查看一下，下面文章，欢迎点赞，收藏，关注三连，感谢！
高可用系列文章：
削峰和填谷
技术源于生活
削峰填谷（Peak cut）是调整用电负荷的一种措施。
根据不同用户的用电规律，合理地、有计划地安排和组织各类用户的用电时间。
以降低负荷高峰，填补负荷低谷。减小电网负荷峰谷差，使发电、用电趋于平衡。
在我们理解的削峰填谷的流量趋势图，如下图所示，在流量高峰阶段削去高峰流量，在流量下降时，填补这部分流量,使流量趋向平衡。
简单概述一下，削峰 和 填谷
- 削峰： 为保证服务可用，剔除部分流量。 --业务有损
- 填谷： 在服务能力盈余的情况下，提供补偿操作。 --业务补偿
削峰
通过削去流量尖刺，让请求流量趋向平稳，以保障服务的稳定性。
- 客户端削峰
- 服务端削峰
上面有提到，削峰是业务有损的行为，削掉的这部分流量，可能在电商系统中，致使我们丢失这个用户。
1、客户端削峰
在后端的思维里面，削峰动作更多是服务端同学的工作和思考。但是在整体系统的设计中，客户端的削峰也是必不可少的。通过客户端的削峰，可以削减服务端的压力，从而保障系统的可用性。
1.1、资源动静分离
这个方案比较简单，或者说目前基本都采用的方式。通过将静态资源与服务端隔离，在活动开始前，将资源预热到CDN，减轻服务端的压力。客户端与服务端的交互，只有动态数据的交互。
1.2、请求削峰
1、设置两次请求最小有效时间间隔
设置两次请求之间的时间间隔为 t， 在每次请求间隔内的请求，都会被忽略掉，不向服务的发起请求，假设 t 秒内，每个用户只会触发一次有效请求，对应的 qps 为 1/t，如果用户量为 Q， 那么最大的 qps 为 Q / t。
2、公平性策略
每个用户一次活动周期内有效请求概率是P，比如概率0.2，也就是5次中1次请求机会，或者10次中2次请求机会。根据随机算法+插值算法生成请求序列：
根据上述方式就可以得到公平性策略，粒度可以自由把控
2、服务端削峰
2.1、限流削峰
在之前的限流相关文章中有介绍到，服务端限流主要有
- 网关限流
- 容器限流
- 服务器限流
在服务器限流中， 主要介绍了，使用Sentinel 来做流量控制，通过下面的流量图可以看到，流量控制在了 2 qps ，峰值流量通过快速失败的方式返回。 那么，对于这部分被拒绝的流量，我们从业务角度来看的话，是有损的。
2.2、MQ削峰
在消息队列的架构中，有 pull 和 push 两种消息同步的方式，我们可以通过下游系统 订单系统 主动拉取pull 的方式，来保障下游服务的流量稳定。
那么，我们是否可以脱了了限流，只通过 MQ 的方式，来达到削峰呢？ 答案是： 不能！
假设秒杀系统的 流量是 ： 10000 qps，订单系统的消费能力只有 100qps。活动时间如果持续比较长，会产生消息堆积过多。 一方面会对消息中间件造成压力，另一方面，消息的有效性也没办法保障。
因此在这个链路图中，实际场景会是这样子：
流量先经过 Sentinel等限流中间件的调平后，由秒杀系统提交 MQ 任务。
填谷
从上面的削峰策略可以看到，大部分的削峰 都是业务有损的，从客户端发起请求限流 ,到服务端的中间件限流。对于这部分的请求，都是直接丢弃的。而在 MQ削峰 的场景下，我们可以通过将请求缓存 的方式，减缓流量压力，有下游服务来控制请求压力，从而达到削峰的效果。
脱离了削峰，就不存在填谷了
在 MQ削峰 的场景中，我们主要保障的是 订单系统 的流量稳定性, 如果 秒杀系统的消息流量为 100tps，订单系统的处理能力为 200tps，那么，对于下游系统来说，就不存在峰值流量了！
如有其他场景，可以交流纠正
填谷补偿
在峰值流量阶段，出现部分流量无法得到马上的处理，通过峰值流量过去后，在消费能力盈余的情况下，对之前的请求做补偿操作，使整体流量趋向于平稳。
比如在上述链路图中，秒杀活动持续了 1分钟，
- 产生请求为：
60 * 100 = 6000个请求。 - 消费时间为：
6000 / 50 = 120秒。
在用户可接受的范围内（1分钟的等待），获取自己的秒杀下单结果。同时对订单系统的负载做好保护。
消息队列的风险
相对于其他的削峰方案，看起来MQ削峰方案是最优的，那为什么我们在 流控方案上，还是更加注重限流方案上。而不是统一使用 MQ削峰呢？
每个方案都存在利弊，引入 MQ，能为我们解决 削峰，异步和解耦等问题。但是，在引入MQ中间件的同时，也会为我们带来以下的问题：
中间件可用性：MQ队列不可用，会导致整个链路不可用，严重会造成雪崩消息可靠性：消息发送，消费需要得到保障消息堆积：消息生产过快，导致MQ中间件压力过大消息重复：消费幂等能力支撑消息顺序：部分场景要求消费按照顺序执行
点关注，不迷路
在架构设计中，很重要的一点，每个方案都是有利有弊，而我们在进行架构设计时，需要考虑引入一个解决方案时，权衡这个方案的利弊，最终落地。
好了各位，以上就是这篇文章的全部内容了，下一篇文章会梳理高可用秒杀系统的架构设计 欢迎大家关注。感谢大伙能看到这里，如果这个文章写得还不错， 求三连！！！ 创作不易，感谢各位的支持和认可，我们下篇文章见！
我是 九灵 ,有需要交流的童鞋可以关注公众号：Java 补习课，掌握第一手资料！ 如果本篇博客有任何错误，请批评指教，不胜感激 ！
