Understanding NodeSelectorSlot, ClusterBuilderSlot and StatisticSlot in Backend Resource Management

In the framework’s responsibility chain, NodeSelectorSlot is the first node that processes a request; it is tied to a specific resource name rather than a thread, so the same resource always uses the same NodeSelectorSlot instance.

The slot handles scenarios where different context names invoke the same resource, such as multiple services calling the getUserInfo resource.

All these contexts share the same resource but have separate entry contexts.

Building on this, ClusterBuilderSlot creates a ClusterNode for each resource. If a ClusterNode does not exist for a resource, a new instance is instantiated.

Each resource therefore has a one‑to‑one correspondence with a ClusterNode, which becomes the anchor for statistical collection.

The statistical significance lies in the fact that a ClusterNode aggregates QPS and other metrics for its resource. When the request originates from different callers (the origin field, e.g., application-a or application-b), a StatisticsNode is attached to the ClusterNode to record per‑origin data.

For example, when getUserInfo receives calls from both application-a and

application-b</b>, the internal tree expands to show separate branches for each origin, allowing the dashboard to display origin‑specific QPS.</p>
<img src="https://mmbiz.qpic.cn/mmbiz_jpg/PlhAddctCRUfwuj9K4AeJNrWqR1iaHohT58IktLHtcdic7R6..." />
<p>The <strong>LogSlot</strong> fires after the chain’s downstream nodes. It processes any <code>BlockException

that may have been thrown before logging the request.

Finally, the StatisticSlot fires after all downstream processing, then records statistics. It uses a sliding‑window algorithm for QPS calculation and LongAdder for concurrent thread counting.

QPS statistics – sliding window

Thread concurrency – LongAdder

These slots are typically configured via the dashboard, where rules can be enabled or adjusted. Hard‑coding rules into the code is possible but makes future adjustments cumbersome because each change requires a code redeployment.

Hard‑coding rules is less convenient; using the dashboard allows dynamic configuration without code changes.