SpringBoot3 + ShardingSphere-Proxy5.5.2 运行模式

发表于 更新于 分类于 ， ， 置顶 精品
阅读次数： 本文字数： 1.6k 阅读时长 ≈ 6 分钟

摘要

运行模式说明

  • 运行模式

  • ShardingSphere-Proxy 运行模式分为两种：单机模式(Standalone) 和 集群模式(Cluster)。

  • 运行模式就是指定将元数据(认证、数据源、分片规则等等)持久化的存储方式。

  • 默认运行模式为单机模式，使用H2的内存方式。

单机模式(Standalone)

  • 单机模式目前仅支持一种：JDBC，即数据库持久化。以下为默认值(JDBCRepositoryPropertyKey)。

名称 数据类型 说明 默认值
provider String 元数据存储类型，可选值为 H2、MySQL 、EmbeddedDerby、DerbyNetworkServer、HSQLDB H2
jdbc_url String JDBC URL jdbc:h2:mem:config;DB_CLOSE_DELAY=0;DATABASE_TO_UPPER=false;MODE=MYSQL
username String 账号 sa
password String 密码 空（无默认值）

  • 这里以 Mysql 存储元数据为例，相关属性参考官网说明

1
2
3
4
5
6
7
8
9
mode:
  type: Standalone
  repository:
    type: JDBC
    props:
      provider: MySQL
      jdbc_url: jdbc:mysql://127.0.0.1:3306/shardingsphere?useSSL=false&serverTimezone=UTC&useUnicode=true&characterEncoding=UTF-8
      username: root
      password: newpwd

  • 启动 ShardingSphere Proxy 成功后会自动在上面的数据库中创建一张表，并将配置文件的中的元数据存储进去

1
2
3
4
5
6
7
CREATE TABLE `repository` (
  `id` varchar(36) COLLATE utf8mb4_bin NOT NULL,
  `key` text COLLATE utf8mb4_bin,
  `value` text COLLATE utf8mb4_bin,
  `parent` text COLLATE utf8mb4_bin,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

重点说明

  • 当数据库中不存在该表时，会自动创建该表，并将配置文件的元数据插入该表中。

  • 当数据库中已存在该表时，会读取该表中的数据并将其加载到内存，而不会读取配置文件中的元数据。即此时配置文件中的元数据不会生效。

  • 若此时想修改配置规则，有三种方法：

    • 1.删除该表，修改配置文件后重新启动Proxy，此时会重新创建该表并加载配置文件中的元数据。
    • 2.手工修改数据表中的元数据，但修改后需要重新启动Proxy才会加载新的元数据。但手工修改需要对数据的组织形式非常清楚，否则极易出错。
    • 3.[推荐]登录逻辑数据库后，使用 DistSQL 动态修改配置，修改后的配置会被保存在该表中，并立即生效，无需重启Proxy。

  • 开发和测试环境可以直接使用默认的 H2 内存数据库，生产环境可以使用 MySQL等数据库对元数据进行持久化保存或者使用下面的集群模式。

集群模式(Cluster)

  • 这里以 zookeeper 集群模式为例，相关属性参考官网说明

1
2
3
4
5
6
7
8
9
10
11
mode:
  type: Cluster                 # 运行模式，默认是单机模式 Standalone
  repository:
    type: ZooKeeper             # 注册中心类型，当前版本仅支持 ZooKeeper 和 etcd
    props:
      namespace: governance_ds  # ZooKeeper 上的根路径（逻辑命名空间），ShardingSphere 会把所有元数据（schema 的 data_sources、rules、版本信息、运行时实例节点等）放在该 namespace 下
      server-lists: localhost:2181 # ZooKeeper 集群地址列表，以逗号分隔的 host:port 列表
      retryIntervalMilliseconds: 500 # 与注册中心交互失败后的重试间隔（毫秒）。网络不稳定或短暂故障时用于重试回退。
      timeToLiveSeconds: 60     # 表示“临时/短期数据”的生存时间（秒），用于控制某些临时节点/实例信息的存活策略
      maxRetries: 3             # 最大重试次数（超过则认为操作失败）。
      operationTimeoutMilliseconds: 500  # 单次 ZooKeeper 操作（读写）的超时时间（毫秒）。

重点说明

  • 不要手工修改 Zookeeper 集群中的 namespace 下的配置信息!

  • 既然是集群，就需要多个 ShardingSphere-Proxy 实例。 当第一个 ShardingSphere-Proxy 实例 启动后，其它相同配置的 ShardingSphere-Proxy 实例仅需要一个 global.yaml 全局配置文件即可，并仅需在其中配置上面的运行模式信息，而不需要再配置其它配置，比如认证、数据源、分片规则等信息，这些信息会通过 Zookeeper 集群中的 namespace 获取并保存到本地内存中。

  • 每个 ShardingSphere-Proxy 实例启动时，都会自动将自己注册到 Zookeeper 集群中指定的 namespace 下，并自动获取该 namespace 下的配置信息。

  • 当 Zookeeper 集群中不存在指定的 namespace 时，此时第一次启动 ShardingSphere-Proxy 会自动在 Zookeeper 中创建 namespace，并写入配置文件中的配置信息到 Zookeeper 中。

  • 当 Zookeeper 集群中已存在指定的 namespace 时，此时再启动 ShardingSphere-Proxy 会自动从 Zookeeper 中读取 namespace 下的配置信息，并将其加载到内存中，不会再读取本地配置文件中的配置信息。

  • 当 Zookeeper 集群中已存在指定的 namespace 时，根据上面的规则，此时修改本地的配置文件中的分片规则后重启ShardingSphere-Proxy 并不会生效。

    • 此时有三种方法：
        1. 删除 Zookeeper 集群中指定的 namespace，然后重启 ShardingSphere-Proxy。这种方法有个弊端，即会导致连接到相同 ZooKeeper 集群的 namespace 的其它 ShardingSphere-Proxy 实例数据丢失(完全不可用)，也需要重启才能重新获取到数据。
        1. 手工修改 Zookeeper 集群中指定的 namespace 下的分片规则，修改后会立即同步到所有 ShardingSphere-Proxy 实例。但手工修改需要对数据的组织形式非常清楚，否则极易出错。
        1. [推荐]登录逻辑数据库后，使用 DistSQL 动态修改配置，此时会自动同步到所有 ShardingSphere-Proxy 实例。所以，灵活掌握 DistSQL 是维护 ShardingSphere-Proxy 集群的关键。

  • 多个 ShardingSphere-Proxy 实例 可以通过负载均衡器，比如 Nginx，将请求路由到不同的 ShardingSphere-Proxy 实例。比如：

1
2
3
4
5
6
7
8
9
10
11
12
stream{
    upstream shardingsphere_proxy{
        server  10.10.21.35:3307;
        server  10.10.21.36:3307;
    }
    server{
        listen 3310;
        proxy_connect_timeout 20s;
        proxy_timeout 5m;
        proxy_pass shardingsphere_proxy;
    }
}