1 配置中心
- 配置集中化:
越来越多的运行时实例,使得散落的配置难于管理,配置不同步导致的问题十分严重。将配置集中于配置中心,可以更加有效进行管理。
- 配置动态化:
配置修改后的分发,是配置中心可以提供的另一个重要能力。它可支持数据源、表与分片及读写分离策略的动态切换。
1.1 配置中心数据结构
配置中心在定义的命名空间 config 下,以 YAML 格式存储,包括数据源、数据分片、读写分离、Properties 配置,可通过修改节点来实现对于配置的动态管理。
config
├──authentication # Sharding-Proxy权限配置
├──props # 属性配置
├──schema # Schema配置
├ ├──sharding_db # SchemaName配置
├ ├ ├──datasource # 数据源配置
├ ├ ├──rule # 数据分片规则配置
├ ├──masterslave_db # SchemaName配置
├ ├ ├──datasource # 数据源配置
├ ├ ├──rule # 读写分离规则
config/authentication 认证管理
password: root
username: root
config/sharding/props 属性配置
sql.show: true
config/schema/schemeName/datasource 多个数据库连接池的集合,不同数据库连接池属性自适配(例如:DBCP,C3P0,Druid, HikariCP)。
ds_0:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
properties:
url: jdbc:mysql://127.0.0.1:3306/itbaizhan1?
serverTimezone=UTC&useSSL=false
password: root
username: root
maxPoolSize: 50
minPoolSize: 1
ds_1:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
properties:
url: jdbc:mysql://127.0.0.1:3306/itbaizhan2?
serverTimezone=UTC&useSSL=false
password: root
username: root
maxPoolSize: 50
minPoolSize: 1
config/schema/sharding_db/rule
数据分片配置,包括数据分片配置。
tables:
t_order:
actualDataNodes: ds_$->{0..1}.t_order_$->{0..1}
databaseStrategy:
inline:
shardingColumn: user_id
algorithmExpression: ds_$->{user_id % 2}
keyGenerator:
column: order_id
logicTable: t_order
tableStrategy:
inline:
shardingColumn: order_id
algorithmExpression: t_order_$->{order_id % 2}
t_order_item:
actualDataNodes: ds_$->{0..1}.t_order_item_$->{0..1}
databaseStrategy:
inline:
shardingColumn: user_id
algorithmExpression: ds_$->{user_id % 2}
keyGenerator:
column: order_item_id
logicTable: t_order_item
tableStrategy:
inline:
shardingColumn: order_id
algorithmExpression: t_order_item_$->{order_id % 2}
bindingTables:
- t_order,t_order_item
broadcastTables:
- t_config
defaultDataSourceName: ds_0
masterSlaveRules: {}
config/schema/masterslave/rule
读写分离独立使用时使用该配置。
name: ds_ms
masterDataSourceName: ds_master
slaveDataSourceNames:
- ds_slave0
- ds_slave1
loadBalanceAlgorithmType: ROUND_ROBIN
动态生效
在注册中心上修改、删除、新增相关配置,会动态推送到生产环境并立即生效。
2 注册中心
相对于配置中心管理配置数据,注册中心存放运行时的动态或临时状态数据,比如可用的proxy的实例,需要禁用或熔断的 datasource 实例。
通过注册中心,可以提供熔断数据库访问程序对数据库的访问和禁用从库的访问的编排治理能力。治理仍然有大量未完成的功能(比如流控等)。
2.1 注册中心数据结构
注册中心在定义的命名空间的 state 下,创建数据库访问对象运行节点,用于区分不同数据库访问实例。包括 instances 和 datasources 节点。
instances
├──your_instance_ip_a@-@your_instance_pid_x
├──your_instance_ip_b@-@your_instance_pid_y
├──....
datasources
├──ds0
├──ds1
├──....
state/instances
数据库访问对象运行实例信息,子节点是当前运行实例的标识。
运行实例标识由运行服务器的IP地址和PID构成。运行实例标识均为临时节点,当实例上线时注册,下线时自动清理。注册中心监控这些节点的变化来治理运行中实例对数据库的访问等。
state/datasources
可以控制读写分离,可动态添加删除以及禁用。
2.2 熔断实例
可在IP地址@-@PID节点写入DISABLED(忽略大小写)表示禁用该实例,删除DISABLED表示启用。
禁用从库 在读写分离场景下,可在数据源名称子节点中写入DISABLED表示禁用从库数据源,删除 DISABLED 或节点表示启用。
2.3 支持的配置中心和注册中心
ShardingSphere在数据库治理模块使用SPI方式载入数据到配置中心/注册中心,进行实例熔断和数据库禁用。
目前,ShardingSphere 内部支持 Zookeeper 和 Etcd 这种常用的配置中心/注册中心。
此外,也可以使用其他第三方配置中心/注册中心,例如 Apollo、Nacos 等,并通过SPI的方式注入到ShardingSphere,从而使用该配置中心/注册中心,实现数据库治理功能。