热点规则
热点就是经常访问的数据。很多时候我们希望争对某一些热点数据，然后来进行限制。比如说商品的信息这个服务，我们给它做一个限流，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的使用率超过一个百分比，
发生以上这些情况的时候把你整个应用给你断掉。所有服务都不提供了，所有请求都被挡住了。这个设置很少用，因为它太粗了。一般都是做细粒度的流控啊、熔断降级。如果设置了 很可能你都不知道怎么回事 ，你的服务就访问不了。 所以一般很少去这么设置。
系统规则简单了解下就可以了。
