概述
当流量突然增大的时候，我们常常会希望系统从空闲状态到繁忙状态的切换的时间长一些。即如果系统在此之前长期处于空闲的状态，我们希望处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值。Warm Up（冷启动，预热）模式就是为了实现这个目的的。
这个场景主要用于启动需要额外开销的场景，例如建立数据库连接等。
它的实现是在 Guava 的算法的基础上实现的。然而，和 Guava 的场景不同，Guava 的场景主要用于调节请求的间隔，即 Leaky Bucket，而 Sentinel 则主要用于控制每秒的 QPS，即我们满足每秒通过的 QPS 即可，我们不需要关注每个请求的间隔，换言之，我们更像一个 Token Bucket。
我们用桶里剩余的令牌来量化系统的使用率。假设系统每秒的处理能力为 b,系统每处理一个请求，就从桶中取走一个令牌；每秒这个令牌桶会自动掉落b个令牌。令牌桶越满，则说明系统的利用率越低；当令牌桶里的令牌高于某个阈值之后，我们称之为令牌桶"饱和"。
当令牌桶饱和的时候，基于 Guava 的计算上，我们可以推出下面两个公式:
rate(c)=m*c+ coldrate
其中，rate 为当前请求和上一个请求的间隔时间，而 rate 是和令牌桶中的高于阈值的令牌数量成线形关系的。cold rate 则为当桶满的时候，请求和请求的最大间隔。通常是 coldFactor * rate(stable)。
通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：
默认 coldFactor 为 3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。
Demo 示例
WarmUpFlowDemo 演示了如何使用冷启动。
warmupFlowRule()通过设置下列的参数，构建了一个流控规则：
FlowRule rule = new FlowRule();
rule.setResource(resourceName);
rule.setCount(20);
rule.setGrade(RuleConstant.GRADE_QPS);
rule.setLimitApp("default");
rule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP);
rule.setWarmUpPeriodSec(10);其中，CONTROL_BEHAVIOR_WARM_UP 表示启用冷启动模式，warmUpPeriodSec 代表期待系统进入稳定状态的时间（即预热时长）。
-
coldSystem()则是通过调节qpsInColdPeriod的大小，让系统长时间的处于冷的状态。 -
simulateTraffic()则通过调节threadCount的大小，来模拟大流量的情况 -
观察输出:
Large amount of traffic is coming
88 send qps is: 2061
1528883307808,total:2061, pass:9, block:2053
87 send qps is: 3699
1528883308808,total:3699, pass:7, block:3692
86 send qps is: 3898
1528883309808,total:3898, pass:7, block:3893
85 send qps is: 3713
1528883310808,total:3713, pass:7, block:3708
84 send qps is: 3756
1528883311808,total:3756, pass:8, block:3749
83 send qps is: 3750
1528883312808,total:3750, pass:9, block:3741
82 send qps is: 3492
1528883313806,total:3492, pass:10, block:3482
81 send qps is: 3923
1528883314808,total:3923, pass:11, block:3913
80 send qps is: 3176
1528883315820,total:3176, pass:13, block:3163
79 send qps is: 3729
1528883316821,total:3729, pass:22, block:3708
78 send qps is: 3534
1528883317820,total:3534, pass:20, block:3514
可以看到第 10 秒的时候，系统开始稳定的接受 20 个请求。
