Standard flow control applies uniform rate limits across all traffic on an interface. When a small set of parameter values drives disproportionate load -- such as a few product IDs during a flash sale or a handful of abusive user IDs -- uniform limits are too coarse. Hot parameter throttling identifies these high-frequency values using a least recently used (LRU) policy and applies per-value rate limits based on the token bucket algorithm. This protects your services without affecting traffic from normal parameter values.
Scenarios
Hot data refers to the frequently accessed data. You may need to collect statistics on the most frequently accessed data and perform access control in scenarios such as the following:
Cache breakdown prevention: Restrict the access to the IDs of the most frequently purchased products in a period of time to prevent a large number of requests from being sent to a database due to cache breakdowns.
Anti-brushing: Restrict the access from the IDs of users who frequently send requests in a period of time to prevent brushing.
How hot parameter throttling works
MSE uses an LRU policy to collect statistics on the hot parameters that are most frequently accessed and throttles resource calls that involve hot parameters based on the token bucket algorithm.
Step 1: Open the rule creation dialog
Log on to the MSE console and select a region in the top navigation bar.
In the left-side navigation pane, choose Microservices Governance > Application Governance.
On the Application list page, click the resource card of the target application.
Open the Add Hot Parameter Protection (RPC/Custom Interface) dialog using one of the following methods:
From the API Details page
In the left-side navigation pane, click API Details.
For an RPC interface: Click the RPC service tab, select the interface, click the Hotspot Parameter Protection (RPC) tab in the right-side pane, and then click Add Hotspot Parameter Protection (RPC) Rule.
For a custom interface: Click the Custom Interface tab, select the interface, click the Hotspot Parameter Protection tab in the right-side pane, and then click Add Hot Parameter Protection (Custom Interface) Rule.
From the Traffic management page
In the left-side navigation pane, click Traffic management. Click the Flow protection tab, click the Hot Parameter Protection (RPC/Custom Interface) subtab, and then click Add Hot Parameter Protection (RPC/Custom Interface).
Step 2: Configure the rule
In the Add Hot Parameter Protection (RPC/Custom Interface) dialog, configure the following parameters, and then click New.
| Parameter | Description |
|---|---|
| Interface name | The name of the interface to which you want to apply the rule. The name must be the same as the resource name specified during tracking. |
| Parameter position Index | The zero-based index of the parameter to track. Maps to the parameter list of the RPC method or custom tracking method. See How parameter indexing works. |
| Statistical dimension | The metric used for throttling. See Choose a statistical dimension. |
| Statistical cycle time | The length of the time window, in seconds. For example, if set to 10 with a threshold of 5, each hot parameter value is accessed at most 5 times within every 10-second window. |
| Single machine threshold | The QPS threshold for each hot parameter value. |
| Flow control effect | How excess requests are handled. Available only when Statistical dimension is set to Number of requests. See Choose a flow control effect. |
How parameter indexing works
The index is zero-based and maps to the parameter list of your method signature:
RPC method: For
com.aliyun.demo:methodA(param0, param1, ……), index0refers toparam0.Custom tracking method: For
SphU.entry("demoResource", EntryType.IN, 1, param0, param1, ……), index0refers toparam0.
Choose a statistical dimension
Use this table to select the appropriate dimension for your use case:
| Dimension | Behavior | Best for |
|---|---|---|
| Number of requests | Limits the total number of requests within a time window. Supports configurable flow control effects (fast failure or queuing). | Read-heavy workloads where you want to smooth traffic spikes, such as product queries during flash sales. |
| Concurrent number | Limits the maximum number of requests processed concurrently. Excess requests are rejected immediately (fast failure only). Flow control effect is not configurable in this mode. | Write-heavy or resource-intensive operations where queuing would increase database contention, such as bulk address updates. |
Choose a flow control effect
When Statistical dimension is set to Number of requests, choose one of the following effects:
| Effect | Behavior | Best for |
|---|---|---|
| Fast failure | Immediately rejects requests that exceed the threshold. Set Number of buffered requests to allow a small burst above the threshold. | Low-latency scenarios where rejected requests can be retried by the client. |
| Waiting in line | Queues excess requests and processes them at a constant rate. Specify a Timeout value in milliseconds. If the estimated queuing duration exceeds the specified timeout period, the request is directly rejected. | Peak-load shifting scenarios such as message queue (MQ) consumption, where dropping requests is undesirable. |
How queuing works: With a threshold of 5, the system processes one request every 200 milliseconds. If the timeout is 1,000 milliseconds and more than 5 requests are queued, the additional requests are rejected.
Configuration examples
Example 1: Queue excess requests during flash sales
During a flash sale, a small number of product IDs generate massive traffic. To keep the system stable, queue requests that exceed the threshold instead of dropping them immediately.
Goal: Process up to 100 requests per second per hot parameter value. Queue excess requests with a 30-millisecond timeout.
| Parameter | Value |
|---|---|
| Interface name | Your flash sale interface resource name |
| Parameter position Index | The index of the product ID parameter (for example, 0) |
| Statistical dimension | Number of requests |
| Statistical cycle time | 1 (second) |
| Single machine threshold | 100 |
| Flow control effect | Waiting in line |
| Timeout | 30 (milliseconds) |
Result: When a hot parameter value exceeds 100 requests within 1 second on a single instance, excess requests are queued. Any request whose estimated wait time exceeds 30 milliseconds is rejected immediately.
Example 2: Reject excess requests for resource-intensive operations
During flash sales, users may modify shipping addresses in bulk. These write-heavy requests consume significant database resources. Reject excess requests immediately to protect the system.
Goal: Allow up to 100 concurrent requests per hot parameter value. Reject any excess immediately.
| Parameter | Value |
|---|---|
| Interface name | Your address update interface resource name |
| Parameter position Index | The index of the user ID or order ID parameter (for example, 0) |
| Statistical dimension | Concurrent number |
| Statistical cycle time | 1 (second) |
| Single machine threshold | 100 |
When Statistical dimension is set to Concurrent number, excess requests are rejected immediately (fast failure). The Flow control effect parameter is not available in this mode.
Result: The system can process up to 100 concurrent requests per hot parameter value. Excess requests fail immediately.