shading-proxy服务入门配置

简介

Sharding-Proxy是一个分布式数据库中间件，定位为透明化的数据库代理端。主要功能是分库分表，他是一个独立部署的服务端，提供统一的数据库代理服务，注意，ShardingProxy目前只支持MySQL和PostgreSQL。你可以把它这个中间件当做一个数据库来看,也可以把它当成一个封装的sharding-jdbc服务。它的整体架构图如下：

下载

地址：https://shardingsphere.apache.org/document/legacy/4.x/document/en/downloads/

部署

下载下来之后，直接在本地解压，windows和Linux上提供了一套统一的部署发布包，但是注意lib目录的jar包后缀是否完整，不完整的手动补齐。

配置

具体配置可以看官方文档。官网文档地址，以下是我自己配置。
1.修改server.yaml，将配置文件中的authentication和props两段配置的注释打开。shardingRule是核心配置，主要配置分表算法，不熟悉的建议从sharding-jdbc学起。

#proxy数据库名称
schemaName: test_project

dataSources:
  project:
    url: jdbc:mysql://192.168.1.110:3306/my_test_project?serverTimezone=UTC&useSSL=false
    username: root
    password: 1234
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  project_0:
    url: jdbc:mysql://192.168.1.110:3306/my_test_project0?serverTimezone=UTC&useSSL=false
    username: root
    password: 1234
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50
  project_1:
    url: jdbc:mysql://192.168.1.110:3306/my_test_project1?serverTimezone=UTC&useSSL=false
    username: root
    password: 1234
    connectionTimeoutMilliseconds: 30000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 50

shardingRule:
  tables:
    pub_org:
      actualDataNodes: project_${0..1}.pub_org$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: pub_org$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88 
    sys_dept:
      actualDataNodes: project_${0..1}.sys_dept$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: sys_dept$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88
    sys_grade:
      actualDataNodes: project_${0..1}.sys_grade$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: sys_grade$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88 
    sys_patriarch:
      actualDataNodes: project_${0..1}.sys_patriarch$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: sys_patriarch$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88 
    sys_student:
      actualDataNodes: project_${0..1}.sys_student$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: sys_student$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88 
    sys_teacher:
      actualDataNodes: project_${0..1}.sys_teacher$->{0..1}
      tableStrategy:
        inline:
          shardingColumn: id
          algorithmExpression: sys_teacher$->{id%2}
      keyGenerator:
        type: SNOWFLAKE
# 自定义的主键生成器
# type: MYKEY 
        column: id
        props:
# 自定义的主键生成偏移量
          mykey-offset: 88 
          
  #主库
  defaultDataSourceName: project

2.修改conf目录下的config-sharding.yaml，这个配置文件就是shardingProxy关于分库分表部分的配置。整个配置和之前我们使用ShardingJDBC时的配置大致相同，我们在最下面按照自己的数据库环境增加以下配置：

#账号为root，密码为sharding（不要按照官网配置）
authentication:
  users:
    root:
      password: sharding

props:
  max.connections.size.per.query: 2
  acceptor.size: 16  # The default value is available processors count * 2.
  executor.size: 16  # Infinite by default.
  proxy.frontend.flush.threshold: 128  # The default value is 128.
  # LOCAL: Proxy will run with LOCAL transaction.
  # XA: Proxy will run with XA transaction.
  # BASE: Proxy will run with B.A.S.E transaction.
  proxy.transaction.type: LOCAL
  proxy.opentracing.enabled: false
  proxy.hint.enabled: false
  query.with.cipher.column: true
  #打印sql
  sql.show: true
  allow.range.query.with.inline.sharding: false

3.启动
修改完以上两个配置，我们就可以启动ShardingProxy的服务了。启动脚本在bin目录下。其中，windows平台对应的脚本是start.bat，Linux平台对应的脚本是start.sh和stop.sh。
注意：​ 启动时，我们可以直接运行start.bat脚本，这时候，ShardingProxy默认占用的是3307端口。为了不跟我们之前搭建的多个MySQL服务端口冲突，我们定制下启动端口，改为3316端口，当然也可以是其他端口，只要不和本地的端口冲突就可以。
命令：start.bat 18080
启动完成就是这个样子

4.连接

总结

整个sharding + proxy的所有这些功能，本质上其实都只解决了一个问题，就是单机数据库容量的问题。在软件层面对硬件资源进行管理，从而便于对数据库的横向扩展。但是我们也要意识到也他给我们带来了很多问题，例如对业务的侵入大。业务系统写的SQL将不再是纯粹的能在服务器上运行的SQL了，对大量跨维度的JOIN、聚合、子查询、排序等功能在业务上很难进行验证。这必然会弱化数据库的功能。

​ 并且，使用ShardingSphere管理后，数据库之间变成了结合非常紧密的依赖关系，对整个集群的扩容也会带来相当大的难度。

​ 另外，ShardingSphere这种方式实际上将原本由业务管理SQL的工作方式，转化成了由业务管理逻辑SQL，而运维管理实际SQL的混合工作模式，再加上一大堆服务的引入，整个服务运维的维护工作量以及工作难度也上升了非常多。