阅读 4902

没有预热,这不叫高并发,叫并发高

更多精彩文章。

《微服务不是全部,只是特定领域的子集》

《“分库分表" ?选型和流程要慎重,否则会失控》

这么多监控组件,总有一款适合你

《使用Netty,我们到底在开发些什么?》

《这可能是最中肯的Redis规范了》

《程序员画像,十年沉浮》

最有用系列:

《Linux生产环境上,最常用的一套“vim“技巧》

《Linux生产环境上,最常用的一套“Sed“技巧》

《Linux生产环境上,最常用的一套“AWK“技巧》


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

现象举例

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

一、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”的方式。有时很有效但不总是有效,通常很放心但不总是放心。
一切随你。毕竟没有前戏直奔主题,那叫鲁莽。

更多精彩文章。

《微服务不是全部,只是特定领域的子集》

《“分库分表" ?选型和流程要慎重,否则会失控》

这么多监控组件,总有一款适合你

《Linux生产环境上,最常用的一套“vim“技巧》

《使用Netty,我们到底在开发些什么?》

Linux五件套之类的。

《Linux之《荒岛余生》(一)准备篇》

《Linux之《荒岛余生》(二)CPU篇》

《Linux之《荒岛余生》(三)内存篇》

《Linux之《荒岛余生》(四)I/O篇》

《Linux之《荒岛余生》(五)网络篇》

关注下面的标签,发现更多相似文章
评论