热点规则
热点就是经常访问的数据。很多时候我们希望争对某一些热点数据,然后来进行限制。比如说商品的信息这个服务,我们给它做一个限流,qps是100,某一天我想做一个秒杀活动,可能会有很大的流量,这个时候一个商品的qps就达到100了,这个时候就会把流量给他控制住。其他的商品就都看不了。
我希望秒杀这个商品,只把秒杀这个上商品id来的请求,它的qps限制在50,剩下还能留下50给我其他的商品。这是我们碰到的场景。
这个时候我们就需要我们能根据请求的参数来做限流。带的参数是我的热点参数,就给你应用一个特殊的规则。没带我的热点参数,非热点有另外一个限流规则。但是他们调用的是同一个服务。
说白了就是,针对同一个资源,针对不同的参数做不同的流量规则。
sentinel里面这个规则怎么去实现
给getInfo方法加上sentinel的注解。做成一个Resource,然后才可以根据getInfo来制定一些规则
我们根据id的参数不同做限流的规则
这样我就声明了一个新的资源。
启动orderAPI
返回回来就是一个订单信息。
这样服务就调用通了,有了一些流量后。
id为1的qps是1,不是1 的qps是10.
现在传的是2 qps是10怎么点 都不会有限流的问题。
换成id为1,如果一旦点快了。返回500 就说明被限流了。
id是1的时候抛出了ParamFlowException的异常
id是2的都没有被限流。
系统规则
和其他的规则不太一样,它是争对应用来设的。前面设置的都是争对某一个资源。某一个方法来设置的。
系统规则是争对当前这个orderAPI应用整天来设置的。
load是负载,只有在linux机器上才会生效。根据当前系统的负载来决定是不是触发保护。
RT:这个应用上所有的流量的平均的相应时间,也就是我orderAPi上有好多服务,这些所有服务的平均响应时间超过一个值,那么我就停止接收新的请求,
线程数:所有服务访问的线程数加起来
入口qps:所有服务的qps加起来达到一个值
cpu使用率:cpu的使用率超过一个百分比,
发生这些情况的时候把你整个应用给你断掉。所有服务都不提供了,所有请求都被挡住了。这个设置很少用,因为它太粗了。一般都是做细粒度的流控啊、熔断降级。如果设置了 很可能你都不知道怎么回事 ,你的服务就访问不了。 所以一般很少去这么设置。
系统规则简单了解下就可以了。
结束