How Sentinel Implements Rate Limiting: Deep Dive into Its Core Source Code

Sentinel offers extensive rate‑limiting and circuit‑breaking capabilities, allowing configuration via a console, supporting cluster‑wide limits, and visualizing service call statistics. This article focuses on dissecting Sentinel’s rate‑limiting source code.

Core Architecture

Sentinel’s core links different Slot objects in a responsibility‑chain pattern, combining functionalities such as rate limiting, degradation, and system protection. The chain consists of two main parts:

Statistic construction (statistic)

Rule checking (rule checking)

Data Statistics Module

Sentinel treats each protected endpoint as a Resource . It monitors both QPS and concurrent thread count for each resource. Accurate statistics are essential for deciding whether a new request can pass.

StatisticNode

The StatisticNode class implements the statistic part of the slot chain. It uses a sliding‑window algorithm to record the last 60 seconds of data, with each bucket representing one second.

BucketLeapArray

The ArrayMetric class relies on BucketLeapArray, which internally uses a BucketLeapArray of 60 windows (each 1 second). Each window is a WindowWrap instance holding the count for that second.

When adding data, Sentinel determines the current window via timeMillis % 60000 / 1000, checks if the window is expired (older than one minute), and resets it if necessary. Aggregating the values of all non‑expired windows yields the QPS for the past minute.

Key Methods

The core logic resides in currentWindow(long timeMillis) and values(long timeMillis), which retrieve the active window and compute the sum of valid windows respectively.

Context Management

Sentinel uses ContextUtil to manage call‑chain contexts stored in a ThreadLocal. Each context has a name (e.g., "user-center") and an origin identifier. The context creates an EntranceNode at the root of the call chain, enabling distinct tracing for different entry points. ContextUtil.enter("user-center", "app-A"); If ContextUtil.enter is not called, Sentinel falls back to the default context sentinel_default_context with a single default entrance node.

BlockException

When a request exceeds the configured limits, Sentinel throws a BlockException, which can be caught and handled (often leading to fallback or degradation logic).

Entry API

The primary entry point is SphU.entry. Its parameters include:

Resource name : a string that uniquely identifies the protected resource.

Resource type (EntryType): either IN for inbound traffic or OUT for outbound calls, influencing which system‑level rules apply.

System‑level slots ( SystemSlot) use the resource type to decide whether adaptive rate limiting based on system health should be applied.

Slot Chain Construction

Sentinel provides an SPI for customizing the slot chain via SlotChainBuilder. The default implementation ( DefaultSlotChainBuilder) creates a global chain shared by all resources; different resources use the same chain instance, while distinct resources are distinguished by their names.

References

https://juejin.cn/post/6906302891875647495

https://github.com/alibaba/Sentinel/wiki/Sentinel-%E6%A0%B8%E5%BF%83%E7%B1%BB%E8%A7%A3%E6%9E%90

https://www.javadoop.com/post/sentinel