熱點規則
熱點就是經常訪問的數據。很多時候我們希望爭對某一些熱點數據，然后來進行限制。比如說商品的信息這個服務，我們給它做一個限流，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的使用率超過一個百分比，
發生以上這些情況的時候把你整個應用給你斷掉。所有服務都不提供了，所有請求都被擋住了。這個設置很少用，因為它太粗了。一般都是做細粒度的流控啊、熔斷降級。如果設置了 很可能你都不知道怎么回事 ，你的服務就訪問不了。 所以一般很少去這么設置。
系統規則簡單了解下就可以了。
結束