Shulou(Shulou.com)06/01 Report--

This article is to share with you about how the configuration system in ShardingSphere is designed. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

What is a line expression?

Line expression is a tool used to simplify and unify configuration information in ShardingSphere, which is widely used in the daily development process. It's intuitive to use, as long as you use the ${expression} or $- > {expression} expressions in the configuration.

Based on the line expression syntax, ${begin..end} represents a range from "begin" to "end", while multiple ${expression} can use "." Symbols are concatenated to represent a Cartesian product relationship between the values of multiple expressions.

Similar scenarios can use enumerations to enumerate all possible values. The line expression also provides ${[enum1, enum2,... , enumx]} syntax to represent enumerated values, so the effect of "ds$ {0.1} .user ${0.1}" is equivalent to "ds$ {[0jue 1]} .user ${[0J 1]}".

Because ${expression} conflicts with the property file placeholder of Spring itself, and Spring is the current mainstream development framework, it is recommended that you use $- > {expression} to configure it in the formal environment.

What are the core configurations of ShardingSphere?

For sub-database sub-table and read-write separation operation, the main task of configuration is to complete the creation and initialization of various rules. Configuration is not only the core of the whole ShardingSphere, but also the drug grabbing work in our daily development process. It can be said that as long as we master the core configuration items of ShardingSphere, we are equivalent to mastering the use of this framework. So, what are the core configurations of ShardingSphere? Here, we take the sharding engine as an example to introduce the most commonly used configuration items, while we will expand the configuration items related to read-write separation, data desensitization and orchestration governance when introducing specific application scenarios.

ShardingRuleConfiguration

DataSource is the entrance to our use of ShardingSphere. A ShardingDataSourceFactory class is used in the process of creating DataSource, and a ShardingRuleConfiguration object is passed in the constructor of this factory class. Obviously, from a naming point of view, this ShardingRuleConfiguration is the configuration entry for sharding rules.

There are many rules that need to be configured in ShardingRuleConfiguration. Here is a simple illustration.

In fact, for ShardingRuleConfiguration, there is only one configuration item that must be set, namely TableRuleConfiguration.

TableRuleConfiguration

In terms of naming, TableRuleConfiguration is the configuration of table sharding rules, but in fact, this class contains settings for both sub-database and sub-table scenarios, and TableRuleConfiguration contains many important configuration items:

ActualDataNodes: represents a real data node, consisting of data source name and table name, and supports row expressions. For example: ds$ {0.. 1} .user ${0.. 1}

DatabaseShardingStrategyConfig: represents the split table policy. If it is not set, the default table dividing policy will be used. The default dividing table policy here also comes from the defaultTableShardingStrategyConfig configuration in ShardingRuleConfiguration.

KeyGeneratorConfig: represents the configuration of self-increasing column generator in distributed environment. The generator implementation of distributed ID such as snowflake algorithm is integrated in ShardingSphere.

ShardingStrategyConfiguration

The type of both dataBaseShardingStrategyConfig and tableShardingStrategyConfig is a ShardingStrategyConfiguration object. In ShardingSphere, ShardingStrategyConfiguration is actually an empty interface, and there are a series of implementation classes, each of which represents a sharding strategy:

In these specific slicing strategies, it is usually necessary to specify a sharding column shardingColumn and one or more slicing algorithms ShardingAlgorithm.

KeyGeneratorConfiguration

As you can imagine, for a self-incrementing column, you first need to specify a column name column in KeyGeneratorConfiguration. At the same time, because there are a number of self-incrementing mechanisms built into ShardingSphere (such as snowflake algorithm SNOWFLAKE and universal unique identifier UUID), it needs to be specified through a type configuration item.

What configuration methods does ShardingSphere provide?

ShardingSphere provides four configuration methods. For different usage scenarios:

Java code configuration

Yaml configuration

Spring Namespace configuration

Spring Boot configuration

[see official website for detailed configuration] (https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-jdbc/configuration/ "see official website for detailed configuration")

How is the configuration system of ShardingSphere realized?

ShardingRuleConfiguration configuration system

For ShardingSphere, the function of configuration system is essentially to initialize JDBC objects such as DataSource. For example, ShardingDataSourceFactory creates a ShardingDataSource object based on the incoming data sources Map, ShardingRuleConfiguration, and Properties:

Public final class ShardingDataSourceFactory {public static DataSource createDataSource (final Map dataSourceMap, final ShardingRuleConfiguration shardingRuleConfig, final Properties props) throws SQLException {return new ShardingDataSource (dataSourceMap, new ShardingRule (shardingRuleConfig, dataSourceMap.keySet ()), props);}

In ShardingSphere, all rule configuration classes implement a top-level interface, RuleConfiguration. RuleConfiguration is an empty interface, and ShardingRuleConfiguration is one of the implementation classes of this interface, which is specially used to deal with the application scenarios of the sharding engine. The following code is the implementation of the ShardingRuleConfiguration class:

Public final class ShardingRuleConfiguration implements RuleConfiguration {/ / Table sharding rule list private Collection tableRuleConfigs = new LinkedList (); / bind table rule list private Collection bindingTableGroups = new LinkedList (); / / broadcast table rule list private Collection broadcastTables = new LinkedList (); / / default data source private String defaultDataSourceName; / / default sublibrary policy private ShardingStrategyConfiguration defaultDatabaseShardingStrategyConfig; / / default subtable policy private ShardingStrategyConfiguration defaultTableShardingStrategyConfig / / default self-incrementing value generator private KeyGeneratorConfiguration defaultKeyGeneratorConfig; / / read-write separation rule private Collection masterSlaveRuleConfigs = new LinkedList (); / / data desensitization rule private EncryptRuleConfiguration encryptRuleConfig;}

As you can see, ShardingRuleConfiguration contains a series of configuration class definitions, and through the previous introduction, we have understood the role and use of these configuration classes. Among them, the core TableRuleConfiguration definition is relatively simple, which mainly includes the definition of logical table, real data node, sub-database policy and sub-table policy:

Public final class TableRuleConfiguration {/ / logical table private final String logicTable; / / real data node private final String actualDataNodes; / / sub-library policy private ShardingStrategyConfiguration databaseShardingStrategyConfig; / / sub-table strategy private ShardingStrategyConfiguration tableShardingStrategyConfig; / / self-increasing column generator private KeyGeneratorConfiguration keyGeneratorConfig; public TableRuleConfiguration (final String logicTable) {this (logicTable, null) } public TableRuleConfiguration (final String logicTable, final String actualDataNodes) {Preconditions.checkArgument (! Strings.isNullOrEmpty (logicTable), "LogicTable is required."); this.logicTable = logicTable; this.actualDataNodes = actualDataNodes;}}

No matter which configuration method is adopted, all configuration items are encapsulated and transformed on the basis of these core configuration classes. Finally, the ShardingRuleConfiguration is generated, and then the ShardingDataSource is generated through ShardingDataSourceFatory to get the connection.

Thank you for reading! This is the end of the article on "how to design the configuration system in ShardingSphere". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.