sharding学习-参数解析

1.在解析配置文件之前，需要先说说sharding是如何去扫描配置文件的。

在源码中，是通过这个方法去扫描的配置文件：

private File[] findRuleConfigurationFiles(final File path) {

        return path.listFiles(new FileFilter() {

           

            @Override

            public boolean accept(final File pathname) {

                return RULE_CONFIG_FILE_PATTERN.matcher(pathname.getName()).matches();

            }

        });

    }

可以看出，该方法是通过正则表达式去匹配配置文件的，那么，我们看看正则表达式是什么？

 

可以看出，这个表达式是去匹配以config-开头以.yaml结尾的文件，所以，如果我们要自定义逻辑库配置文件的话，需要按照这个格式才行。

 

2.接下来进入正题，开始参数的分析。

由于sharding目前主要用于两个操作：数据分片及读写分离，所以我们一个一个的去看。

 

首先是读写分离：

schemaName: master_slave_db

 

dataSources:

  ds_master:

    url: jdbc:mysql://localhost:3306/ds_master

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds_slave0:

    url: jdbc:mysql://localhost:3306/ds_slave0

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds_slave1:

    url: jdbc:mysql://localhost:3306/ds_slave1

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

 

masterSlaveRule:

  name: ds_ms

  masterDataSourceName: ds_master

  slaveDataSourceNames:

    - ds_slave0

    - ds_slave1

 

以上为官方提供的配置模板，可以看出，想要读写分离，需要数据库有主从（主备）结构才行，也就是需要服务高可用。

 

接下来，我们一个参数一个参数的去分析：

schemaName--schema名称也就是逻辑数据库名称，为启动服务的必须参数。在官方文档中，希望配置文件的后缀，也就是config-后面的部分能和schemaName一致，方便管理。

 

dataSources：物理数据源集合

ds_master：数据源名称，可以和物理库名不一致，类似于一个别名。

url：数据库jdbc连接信息

username：用户名

password：密码

masterSlaveRule：全局读写分离配置

name：主从集合的名称

masterDataSourceName：主节点名称（需要使用之前定义的数据源名称）

slaveDataSourceNames：从节点名称（同样需要使用定义的数据源你名称），如果头多个，用-或者，分割

 

可以看出，只是配置读写分离的话，还是比较简单的，那么接下来看看数据分片+读写分离

还是老规矩，先上官方配置

 

dataSources:

  ds0:

    url: jdbc:mysql://localhost:3306/ds0

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds0_slave0:

    url: jdbc:mysql://localhost:3306/ds0_slave0

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds0_slave1:

    url: jdbc:mysql://localhost:3306/ds0_slave1

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds1:

    url: jdbc:mysql://localhost:3306/ds1

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds1_slave0:

    url: jdbc:mysql://localhost:3306/ds1_slave0

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

  ds1_slave1:

    url: jdbc:mysql://localhost:3306/ds1_slave1

    username: root

    password:

    connectionTimeoutMilliseconds: 30000

    idleTimeoutMilliseconds: 60000

    maxLifetimeMilliseconds: 1800000

    maxPoolSize: 65

    minPoolSize: 1

    maintenanceIntervalMilliseconds: 30000

 

shardingRule: 

  tables:

    t_order:

      actualDataNodes: ms_ds${0..1}.t_order${0..1}

      tableStrategy:

        inline:

          shardingColumn: order_id

          algorithmExpression: t_order${order_id % 2}

      keyGenerator:

        column: order_id

    t_order_item:

      actualDataNodes: ms_ds${0..1}.t_order_item${0..1}

      tableStrategy:

        inline:

          shardingColumn: order_id

          algorithmExpression: t_order_item${order_id % 2} 

  bindingTables:

    - t_order,t_order_item

  broadcastTables:

    - t_config

 

  defaultDataSourceName: ds0

  defaultDatabaseStrategy:

    inline:

      shardingColumn: user_id

      algorithmExpression: ms_ds${user_id % 2}

  defaultTableStrategy:

    none:

  defaultKeyGenerator:

    type: SNOWFLAKE

 

  masterSlaveRules:

      ms_ds0:

        masterDataSourceName: ds0

        slaveDataSourceNames:

          - ds0_slave0

          - ds0_slave1

        loadBalanceAlgorithmType: ROUND_ROBIN

      ms_ds1:

        masterDataSourceName: ds1

        slaveDataSourceNames:

          - ds1_slave0

          - ds1_slave1

        loadBalanceAlgorithmType: ROUND_ROBIN

 

由于schemaName和datasources和读写分离差不多所以就不赘述了。

shardingRule：分片的策略

tables：分片所包含的表

t_order:表名

actualDataNodes：分片区域描述也就是说明存在哪些分片。官方描述如下所示sharidng 表对应的数据源以及物理名称,需要用表达式处理,表示表实际上在哪些数据源存在,配置示例中,意思是总共存在4个分片master_test_0.t_order0,master_test_0.t_order1,master_test_1.t_order0,master_test_1.t_order1

tableStrategy：表的分片策略，这里需要注意的是，单独设置的策略会覆盖默认的策略

inline：每一行数据的分片策略

shardingColumn：分片列，也就是根据那一列进行分片（路由分发）

algorithmExpression：分片算法，也就是指定了路由到的数据源的名称，也就是把sql发到哪个数据源上去执行

bindingTables：绑定的表，也就是配置的规则需要生效的表，采用yaml格式书写，单行运行逗号分隔，所有bind的表都必须已经配置为逻辑表才行

broadcastTables：广播表，也就是需要数据同步的表，相当于一旦一张表执行sql，那么其他所有表（在其他数据库实例中的同名表）也需要执行相应sql

defaultDataSourceName：默认的数据源名称

defaultDatabaseStrategy：默认库级别sharding规则，会被tables里面定义的规则所替代

inline：行分片规则

shardingColumn：分片列

algorithmExpression：分片算法

defaultTableStrategy：默认表格sharding规则

defaultKeyGenerator：默认主键生成算法，默认为SNOWFLAKE算法

masterSlaveRules：读写分离配置，大体和之前一直，这里有几个参数需要单独说下

loadBalanceAlgorithmType：从库负载均衡策略

loadBalanceAlgorithmClassName：负载均衡算法类名称