没有预热，不叫高并发，叫并发高

大家都知道，高并发系统有三把斧子：缓存、熔断和限流。但还有一把斧子，经常被遗忘在角落里，郁郁不得志，那就是预热。

现象举例
先说两个现象。这些现象，只能在并发高的系统中出现。
好吧，它已经引起了多个故障。

一、DB重启后，瞬间死亡
一个高并发环境下的DB，进程死亡后进行重启。由于业务处在高峰期间，上游的负载均衡策略发生了重分配。刚刚启动的DB瞬间接受了1/3的流量，然后load疯狂飙升，直至再无响应。

原因就是：新启动的DB，各种Cache并没有准备完毕，系统状态与正常运行时截然不同。可能平常1/10的量，就能够把它带入死亡。

二、服务重启后，访问异常
另外一个常见的问题是：我的一台服务器发生了问题，由于负载均衡的作用，剩下的机器立马承载了这些请求，运行的很好。当服务重新加入集群时，却发生了大量高耗时的请求，在请求量高的情况下，甚至大批大批的失败。

引起的原因大概可以归结于：

1、服务启动后，jvm并未完全准备完毕，JIT未编译等。
2、应用程序使用的各种资源未准备就绪。
3、负载均衡发生了rebalance。

这两个问题，都是没有做好预热

Warm Up，即冷启动/预热的方式。当系统长期处于低水位的情况下，流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过”冷启动”，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

我想要这样的曲线。

而不是这样的。

事实要复杂的多
流量是不可预测的，这不同于自然增长的流量，或者人为的***——这是一个从无到有的过程。甚至一些自诩超高速的组件，如lmax的disruptor，在这种突然到来的洪峰之下也会崩溃。

warmup最合适的切入层面就是网关。如图：node4是刚启动的节点，集成在网关中的负载均衡组件，将能够识别出这台刚加入的实例，然后逐步放量到这台机器，直到它能够真正承受高速流量。

假如所有的请求，都经过网关，一切都好办的多，也有像Sentinel 之类的组件进行切入。但现实情况往往不能满足条件。比如：

1、你的应用直接获取了注册中心的信息，然后在客户端组件中进行了流量分配。
2、你的应用通过了一些复杂的中间件和路由规则，最终定位到某一台DB上。
3、你的终端，可能通过了MQTT协议，直接连上了MQTT服务端。

我们进行一下抽象，可以看到：所有这些流量分配逻辑，包括网关，都可以叫做客户端。即所有的warmup逻辑都是放在客户端的，它们都与负载均衡紧密耦合在一起。

解决方式
接口放量
按照以上的分析，通过编码手段控制住所有的客户端调用，即可解决问题。

一个简单的轮询方式

1、我要能拿到所有要调用资源的集合，以及启动时间，冷启动的配置等。
2、给这些资源分配一些权重，比如最大权重为100，配置100秒之后冷启动成功。假如现在是第15秒，则总权重就是100*(n-1)+15。
3、根据算好的权重，进行分配，流量会根据时间流逝逐步增加，直到与其他节点等同。
4、一个极端情况，我的后端只有1个实例，根本就启动不起来。

拿SpringCloud来说，我们就要改变这些组件的行为。

1、ribbon的负载均衡策略。
2、网关的负载均衡策略。

还好，它们都是基础组件，不用来回拷贝代码了。

走马观花
顾名思义，意思就是把所有的接口都提前访问一遍，让系统对资源进行提前准备。
比如，遍历所有的http连接，然后发送请求。
这种方法是部分有效的，一些懒加载的资源会在这个阶段陆续加载进来，但不是全部。
JIT等一些增强功能，可能使得预热过程变得非常的长，走马观花的方式，只能在一定程度上有作用。

再比如某些DB，在启动之后，会执行一些非常有特点的sql，使得PageCache里加载到最需要的热数据。

状态保留
系统在死亡时做一个快照，然后在启动时，原封不动的还原回来。

这个过程就比较魔幻了，因为一般的非正常关闭，系统根本没有机会发表遗言，所以只能定时的，在运行中的系统中做快照。

节点在启动时，再将快照加载到内存中。这在一些内存型的组件中应用广泛。

End
通过比较，我们发现，最靠谱的方式还是进行编码，将warmup逻辑集成在客户端。这个工作可能是痛苦的、漫长的，但结局是美好的。
当然也可以通过“摘除nginx->修改权重->reload nginx”的方式。有时很有效但不总是有效，通常很放心但不总是放心。
一切随你。毕竟没有前戏直奔主题，那叫鲁莽。

更多相关文章

随机推荐