Sentinel限流--流控模式与限流效果

1、簇点链路

簇点链路就是项目内的调用链路（controller -> servcie -> mapper ），链路中被监控的每个接口就是一个资源。

默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），Endpoint可以理解为controller中的每一个方法，每一个端点（Endpoint）就是调用链路中的一个资源。

流控、熔断等都是针对簇点链路中的资源来设置的。

点击流控，可以新增流控规则：

QPS为1，即每秒只允许1次请求，超出的请求会被拦截并报错。

2、流控入门案例

需求：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

• 点击流控，设置QPS

• 打开Jemter，添加测试计划，右键start

• 查看结果树，可以看到确实每秒最多5个请求

• 查看sentinel控制台

3、流控模式：关联模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式（入门案例里的效果）
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

流控模式：关联

关联模式的使用场景如：比如用户支付时需要修改订单状态，同时用户要查询订单。但查询和修改操作会争抢数据库锁，二者为竞争关系。

很明显，我需要优先满足支付，即修改订单状态优先级更高，因此当修改订单业务触发阈值时，需要对查询订单业务限流。直白讲就是，二者竞争，超过阈值时，优先级低的被限流，避免影响优先级高的。

当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。关联资源是优先级高的，在优先级低的上面添加限流规则！

需求：
- 在OrderController新建两个端点：/order/query和/order/update，无需实现业务
- 配置流控规则，当/order/ update资源被访问的QPS超过5时，对/order/query请求限流

• 写两个测试接口资源

@GetMapping("/order/query")
public String queryOrder(){
	return "查询订单成功";
}

@GetMappinng("/order/update")
public String updateOrder(){
	return "更新订单成功";
}

• 很明显，query资源优先级低，在它上面添加流控规则

• jmeter模拟请求/order/update,QPS设置10，按图中设置，这100秒内，update的QPS均大于阈值5

• 访问/order/query，可以看到已被限流

• 但/order/update资源却不被限制

对关联模式做个总结就是;

4、流控模式：链路模式

只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值

例如有两条请求链路：

• /test1 到 /common
• /test2 到 /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：

需求：
- 有查询订单和创建订单业务，两者都需要查询商品。
- 针对从查询订单进入到查询商品的请求统计，并设置限流，QPS<2。

访问资源"查询商品方法"，以上就有两条链路：

• 入口1：查询订单/order/query—>查询商品queryGoods
• 入口2：创建订单/order/save —> 查询商品queryGoods

这里需要对queryGoods添加链路模式限流，从/order/query进入queryGoods方法的QPS限制必须小于2.

但注意默认只有controller中的方法会被监控，Service层的queryGoods方法没有被监控，也就不能配置限流规则，要标记其它方法，需要利用@SentinelResource注解：

@SentinelResource("goods")
public void queryGoods() {   
	System.err.println("查询商品");
}

此外：Sentinel默认会将Controller方法做context整合，认为是由同一个根链路发展来的子链路，从而导致链路模式的流控失效，因此需要修改application.yml，添加配置：

spring:
  cloud:    
   sentinel:      
     web-context-unify: false # 关闭context整合

• 接口与方法资源代码展示

public class OrderService{

	@SentinelResource("goods")
	public void queryGoods(){
		System.out.println("查询商品");
	}
	
}

@Resource
private OrderService orderService;


@GetMapping("/order/query")
public String queryOrder(){
	orderService.queryGoods();  //查商品，形成一个链路
	System.out.println("查询订单");
	return "查询订单成功";	
}

@GetMapping("/order/save")
public String saveOrder(){
	orderService.queryGoods(); //查商品，形成一个链路
	System.out.println("新增订单");
	return "新增订单成功";	

}

• 访问下save和query接口，查看sentinel簇点链路：

• 两个goods都一样，随便选一个点击新增流控按钮

• 打开Jmeter做测试，QPS我设为200/50 = 4 > 2，发送query和save请求：

• 可以看到save不受影响：

• 但query的链路我设置了限流，可以看到每秒总有4-2=2个请求失败：

关于流控模式的总结：

5、流控效果：warm up

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
• warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
• 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

就像剧烈运动前慢跑热身一样，服务器刚启动时，不能直接打满到最大QPS，这就是warm up的限流效果：

warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor，前者为最大QPS，后者为冷启动因子。持续指定时长后，逐渐提高到threshold值。而coldFactor的默认值是3.

例如，我设置QPS的threshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.

需求：
- 给/order/{orderId}这个资源设置限流，最大QPS为10。
- 利用warm up效果，预热时长为5秒

添加流控规则：

Jmeter设置QPS为10，start发起请求：

可以看到刚开始，10个请求只成功3个：

随着时间的推移，达到10，则全部请求都能成功：

查看监控面板：

6、限流效果：排队等待