Spring cloud微服务安全实战-6-10sentinel之热点和系统规则
热点规则
热点就是经常访问的数据。很多时候我们希望争对某一些热点数据，然后来进行限制。比如说商品的信息这个服务，我们给它做一个限流，qps是100，某一天我想做一个秒杀活动，可能会有很大的流量，这个时候一个商品的qps就达到100了，这个时候就会把流量给他控制住。其他的商品就都看不了。
我希望秒杀这个商品，只把秒杀这个上商品id来的请求，它的qps限制在50，剩下还能留下50给我其他的商品。这是我们碰到的场景。
这个时候我们就需要我们能根据请求的参数来做限流。带的参数是我的热点参数，就给你应用一个特殊的规则。没带我的热点参数，非热点有另外一个限流规则。但是他们调用的是同一个服务。
说白了就是，针对同一个资源，针对不同的参数做不同的流量规则。
sentinel里面这个规则怎么去实现
给getInfo方法加上sentinel的注解。做成一个Resource，然后才可以根据getInfo来制定一些规则
我们根据id的参数不同做限流的规则
这样我就声明了一个新的资源。
启动orderAPI
返回回来就是一个订单信息。
这样服务就调用通了，有了一些流量后。就是多点击按钮访问这个服务几次，至少5次以上吧
id为1的qps是1，id不为1 的qps（阀值）是10.
建好的规则
现在传的是2 qps是10，怎么快速的的点击按钮访问 都不会有限流的问题。
换成id为1，如果一但点快了。返回500 就说明被限流了。
id是1的时候抛出了ParamFlowException的异常
id是2的都没有被限流。
系统规则
和其他的规则不太一样，它是针对应用来设的。前面设置的都是争对某一个资源。某一个方法来设置的。
系统规则是争对当前这个orderAPI应用整天来设置的。
load是负载，只有在linux机器上才会生效。根据当前系统的负载来决定是不是触发保护。
RT：这个应用上所有的流量的平均的响应时间，也就是我orderAPi上有好多服务，这些所有服务的平均响应时间超过一个值，那么我就停止接收新的请求，
线程数：所有服务访问的线程数加起来
入口qps：所有服务的qps加起来达到一个值
cpu使用率：cpu的使用率超过一个百分比，
发生以上这些情况的时候把你整个应用给你断掉。所有服务都不提供了，所有请求都被挡住了。这个设置很少用，因为它太粗了。一般都是做细粒度的流控啊、熔断降级。如果设置了 很可能你都不知道怎么回事 ，你的服务就访问不了。 所以一般很少去这么设置。
系统规则简单了解下就可以了。
结束
最新文章
- angular2系列教程（四）Attribute directives
- Ajax表单异步上传（包括文件域）
- vs快捷键大全
- iOS8: Ignore manifest download, already have bundleID
- php部分---PDO;
- pagemap, from the userspace perspective
- PHP5.6.x的新鲜事
- Java基础知识强化之集合框架笔记10：Collection集合使用的步骤
- VS2015使用scanf报错解决方案
- 一致性hash和虚拟节点
- 最基础的mybatis入门demo
- STM32F10x -- 利用IIC协议操作AT24C02
- python--使用递归的方式建立二叉树
- linux下如何源码编译安装vim
- Expm 9_2 有向图的强连通分量问题
- Servlet----------Servlet 概述
- Easy to use cross-platform 3D engines
- Linux nginx目录设置
- python单例模式控制成只初始化一次，常规型的python单例模式在新式类和经典类中的区别。
- ACE.js自定义提示实现方法