一、ShardingSphere-Proxy之分库

将hmms分成hmms-0和hmms-1的步骤如下：

1、创建数据库

创建数据库hmms、hmms-0、hmms-1三个数据库

2、然后在config-sharding.yaml中添加分库配置

# 3、创建客户端连接库
schemaName: hmms

#1、连接mysql
dataSources:
  hmmsdatasources-0:
    url: jdbc:mysql://localhost:3306/hmms-0?serverTimezone=UTC&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1
  hmmsdatasources-1:
    url: jdbc:mysql://localhost:3306/hmms-1?serverTimezone=UTC&useSSL=false
    username: root
    password: 123456
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
    minPoolSize: 1

# 2、分片规则
rules:
- !SHARDING
  tables:
    user:
      actualDataNodes: hmmsdatasources-${0..1}.user-${0..1}   
      tableStrategy:
        standard:
          shardingColumn: useid
          shardingAlgorithmName: use_MOD
      databaseStrategy:  #分库规则
          standard:
            shardingColumn: useid
            shardingAlgorithmName: use_MOD
      keyGenerateStrategy: 
        column: useid
        keyGeneratorName: snowflake
  shardingAlgorithms:
    use_MOD:
      type: MOD
      props:

二、ShardingSphere-Proxy数据查询分库分表原理

对查询语句进行分析： select * from user where useid= 1

方案：

1.SQL解析

2.查询优化

3.SQL路由

4.SQL改写

5.SQL执行

6.结果归并

技术

​ 1、SQL解析

​ SQLParserFacade 配置用于SQL解析的词法分析器和语法分析器入口

​ SQLVisitorFacade SQL 语法树访问器入口

​ 2、路由解析

​ – 使用ModShardingAlgorithm分片算法

​ SQLRouter ShardingSQLRouter 用于处理路由结果

​ 2.1 数据分片

​ ModShardingAlgorithm分片算法

​ 3、SQL改写

​ SQLRewriteContextDecorator ShardingSQLRewriteContextDecorator 用于处理 SQL 改写结果

​ 4、SQL执行

​ SQLExecution SQL执行过程

​ 5、结果归并

​ ResultProcessEngine ShardingResultMergerEngine 用于处理分片结果集归并

过程

1、先取出ProductId % 2 然后进行取模得到 0 1

2、如果结果为0:根据路由ShardingSQLRouter 找到真实表seckill_0 数据就存储到第一张库。如果结果为1:根据路由ShardingSQLRouter 找到真实表seckill_1 数据就存储到第二张表。

总结

ShardingSphere-Proxy的分库分表就介绍到这里了。下面是对应遇到数据库问题方案选择总结。

1.数据库瓶颈

不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1.1 IO瓶颈

第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。

第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。

1.2 CPU瓶颈

第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。

第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。