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：负载均衡算法类名称