05 sentinel rule persistence

Sentinel rule persistence

All sentinel rules are stored in memory, and all rules will be lost after restart. In the production environment, we must ensure the persistence of these rules to avoid loss.

Rule management mode

Whether rules can be persisted depends on the rule management mode. sentinel supports three rule management modes:

Push modeexplainadvantageshortcoming
Original modeThe API pushes the rules to the client and updates them directly to memory to expand the write data source( WritableDataSource ), this is the defaultSimple without any dependencyConsistency is not guaranteed; The rule is saved in memory and disappears after restart. Seriously not recommended for production environments
Pull patternExtended write data source( WritableDataSource ), the client actively polls and pulls rules from a rule management center, which can be RDBMS, files, etcSimple without any dependence; Rule persistenceConsistency is not guaranteed; The real-time performance is not guaranteed. If you pull too frequently, there may be performance problems.
Push ****patternExtended read data source( ReadableDataSource ), the rule center pushes uniformly, and the client monitors changes at any time by registering a listener, such as using Nacos, Zookeeper and other configuration centers. This method has better real-time and consistency guarantee. push mode data source is generally used in production environment.Rule persistence; uniformity;Introducing third-party dependencies

Original mode

Original mode: the rules configured by the console are directly pushed to Sentinel client, that is, our application. It is then saved in memory and lost when the service is restarted

pull mode

pull mode: the console pushes the configured rules to Sentinel client, and the client will save the configured rules in local file or database. In the future, it will regularly query local files or databases to update local rules.

push mode

Push mode: the console pushes the configuration rules to the remote configuration center, such as Nacos. Sentinel client listens to Nacos, obtains the push message of configuration change, and completes the local configuration update.

Introduce dependency

Introduce sentinel into the service to monitor the dependency of nacos:


Configure nacos address

Application in service Configure the nacos address and listening configuration information in the YML file:

            server-addr: localhost:8848 # nacos address
            dataId: orderservice-flow-rules
            groupId: SENTINEL_GROUP
            rule-type: flow # It can also be: grade, authority, param flow

Modify sentinel dashboard source code

SentinelDashboard does not support the persistence of nacos by default, and the source code needs to be modified.

Modifying nacos dependencies

In the pom file of sentinel dashboard source code, the default scope of nacos dependency is test, which can only be used during testing. It should be removed here:


Remove the scope that sentinel datasource Nacos depends on:


Add nacos support

Under the test package of sentinel dashboard, nacos support has been written, and we need to copy it to main.

Modify nacos address

Then, you need to modify the NacosConfig class in the test code:

Modify the nacos address to read application Configuration in properties:

@ConfigurationProperties(prefix = "nacos")
public class NacosConfig {

    //nacos address
    private String addr;

    public ConfigService nacosConfigService() throws Exception {
        //Modify the access profile address to addr
        return ConfigFactory.createConfigService(addr);
	//Add set method
    public void setAddr(String addr) {
        this.addr = addr;
	//Add get method
    public String getAddr() {
        return addr;

    public Converter<List<FlowRuleEntity>, String> flowRuleEntityEncoder() {
        return JSON::toJSONString;

    public Converter<String, List<FlowRuleEntity>> flowRuleEntityDecoder() {
        return s -> JSON.parseArray(s, FlowRuleEntity.class);


In sentinel dashboard application Add nacos address configuration in properties:


Configuring nacos data sources

In addition, you need to modify com alibaba. csp. sentinel. dashboard. controller. FlowControllerV2 class under V2 package:

Make the added Nacos data source effective:

Original appearance:

private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;
private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;

Modified appearance:

private DynamicRuleProvider<List<FlowRuleEntity>> ruleProvider;
private DynamicRulePublisher<List<FlowRuleEntity>> rulePublisher;

Modify front page

Next, we need to modify the front page and add a menu that supports nacos.

Modify sidebar in src/main/webapp/resources/app/scripts/directives/sidebar / HTML file:

Open this part of the comment:

Modify the text:

<li ui-sref-active="active" ng-if="entry.appType==0">
    <a ui-sref="dashboard.flow({app: entry.app})">
    <i class="glyphicon glyphicon-filter"></i>&nbsp;&nbsp;Flow control rules V1</a>

Recompile and package the project

Run maven plug-in in IDEA, compile and package the modified sentinel dashboard:


The startup method is the same as that of the official:

java -jar sentinel-dashboard.jar

If you want to modify the nacos address, you need to add parameters:

java -jar -Dnacos.addr=localhost:8848 sentinel-dashboard.jar

Hard refresh

Open the debugging console in the browser, right-click the refresh button and select "empty cache and force reload"

Only the rules added in flow control rules - nacos can be viewed in nacos

Add flow control rule:

To view rules in Nacos:

The browser access service is refreshed frequently, and the current limit occurs, indicating that the configuration is successful:

Keywords: Java Back-end

Added by lzylzlz on Sun, 20 Feb 2022 11:57:33 +0200