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

更多精彩文章。

《微服务不是所有，只是特定领域的子集》

《“分库分表" ？选型和流程要慎重，不然会失控》

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

《使用Netty，咱们到底在开发些什么？》

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

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

最有用系列：

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

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

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

---

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

现象举例

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

1、DB重启后，瞬间死亡

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

缘由就是：新启动的DB，各类Cache并无准备完毕，系统状态与正常运行时大相径庭。可能日常1/10的量，就可以把它带入死亡。

2、服务重启后，访问异常

另一个常见的问题是：个人一台服务器发生了问题，因为负载均衡的做用，剩下的机器立马承载了这些请求，运行的很好。当服务从新加入集群时，却发生了大量高耗时的请求，在请求量高的状况下，甚至大批大批的失败。

引发的缘由大概能够归结于：

一、服务启动后，jvm并未彻底准备完毕，JIT未编译等。
二、应用程序使用的各类资源未准备就绪。
三、负载均衡发生了rebalance。

---

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

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

我想要这样的曲线。

而不是这样的。

事实要复杂的多

流量是不可预测的，这不一样于天然增加的流量，或者人为的攻击----这是一个从无到有的过程。甚至一些自夸超高速的组件，如lmax的disruptor，在这种忽然到来的洪峰之下也会崩溃。

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

假如全部的请求，都通过网关，一切都好办的多，也有像Sentinel 之类的组件进行切入。但现实状况每每不能知足条件。好比：

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

咱们进行一下抽象，能够看到：全部这些流量分配逻辑，包括网关，均可以叫作客户端。即全部的warmup逻辑都是放在客户端的，它们都与负载均衡紧密耦合在一块儿。

解决方式

接口放量

按照以上的分析，经过编码手段控制住全部的客户端调用，便可解决问题。

一个简单的轮询方式

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

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

一、ribbon的负载均衡策略。
二、网关的负载均衡策略。

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

蜻蜓点水

顾名思义，意思就是把全部的接口都提早访问一遍，让系统对资源进行提早准备。 好比，遍历全部的http链接，而后发送请求。 这种方法是部分有效的，一些懒加载的资源会在这个阶段陆续加载进来，但不是所有。 JIT等一些加强功能，可能使得预热过程变得很是的长，蜻蜓点水的方式，只能在必定程度上有做用。

再好比某些DB，在启动以后，会执行一些很是有特色的sql，使得PageCache里加载到最须要的热数据。

状态保留

系统在死亡时作一个快照，而后在启动时，原封不动的还原回来。

这个过程就比较魔幻了，由于通常的非正常关闭，系统根本没有机会发表遗言，因此只能定时的，在运行中的系统中作快照。

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

End

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

更多精彩文章。

《微服务不是所有，只是特定领域的子集》

《“分库分表" ？选型和流程要慎重，不然会失控》

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

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

《使用Netty，咱们到底在开发些什么？》

Linux五件套之类的。

《Linux之《荒岛余生》（一）准备篇》

《Linux之《荒岛余生》（二）CPU篇》

《Linux之《荒岛余生》（三）内存篇》

《Linux之《荒岛余生》（四）I/O篇》

《Linux之《荒岛余生》（五）网络篇》