关于shardingsphere:ShardingSphere-Mode-模式新起航运行模式详解

在 5.0.0 GA 版本中，Apache ShardingSphere 新增了运行模式的概念，同时提供了 Memory/Standalone/Cluster 3 种配置形式。ShardingSphere 为什么会提供这 3 种运行模式，不同的运行模式在理论的开发应用场景中又有哪些不同呢？

本文将率领大家一起理解 ShardingSphere 5.0.0 全新概念 - 运行模式。

孟浩然

SphereEx 高级研发工程师、Apache ShardingSphere PMC。

曾就任于京东科技，负责数据库产品研发，酷爱开源，关注数据库生态，目前专一于 ShardingSphere 数据库中间件开发以及开源社区建设。

分布式治理是 ShardingSphere 集群部署的根底，在 5.0.0 版本之前，用户须要在配置文件中通过配置 governance 标签来开启分布式治理性能：

governance:    
  name: # 治理名称
  registryCenter: # 配置核心
    type: # 治理长久化类型。如：Zookeeper, etcd
    serverLists: # 治理服务列表。包含 IP 地址和端口号。多个地址用逗号分隔。如: host1:2181,host2:2181 
  overwrite: # 本地配置是否笼罩配置核心配置。如果可笼罩，每次启动都以本地配置为准

长久化用户配置以及元数据信息是分布式治理最次要的性能之一，也是反对 DistSQL 的根本能力。在 5.0.0 系列的文章中，DistSQL 外围开发人员曾经具体和大家介绍了 DistSQL 的概念、语法和应用，以及如何开发本人的 DistSQL。简略回顾一下，DistSQL 为 ShardingSphere 提供了一种数据库化的应用体验，用户能够应用 SQL 的形式来搭建和治理整个 ShardingSphere 分布式数据库生态体系。

作为一个分布式数据库生态系统的操作语言，和规范的 SQL 一样，DistSQL 须要保障操作的任何配置以及元数据都可能被长久化，以保障系统还原时的数据一致性。而在 5.0.0 版本之前，只有开启分布式治理能力实现这个性能，这也是为什么 DistSQL 在开发初期仅反对分布式治理场景下应用的起因。

ShardingSphere 基于现有的分布式治理性能提供的集群部署能力，将领有分布式能力的 ShardingSphere 定义为 集群模式。 集群模式反对 ShardingSphere 作为无状态的计算节点进行多实例部署，同时借助注册核心，实现集群内所有实例的元数据信息的实时同步。集群模式人造反对 DistSQL，借助 DistSQL 能够对集群模式下的计算 / 存储节点进行诸如节点高低线、禁用等治理操作。

为了解决 DistSQL 只能在分布式场景下应用的局限，ShardingSphere 首先须要解决非分布式环境下的元数据存储问题，最简略也是最间接的形式是将元数据写入本地文件中，服务重启时依据配置能够从本地文件加载元数据。与分布式场景的集群模式不同，本地文件无奈在多个 ShardingSphere 实例之间实时共享配置，所有配置更新仅在以后实例失效，这就是 单机模式。

ShardingSphere 5.0.0 版本除了为用户提供更弱小的性能之外，打造稳固敌对的用户 API，继续晋升用户应用体验，也是 ShardingSphere 的产品指标。除了集群模式和单机模式，局部用户有疾速启动集成 ShardingSphere 且无需进行配置长久化的需要，比方应用 ShardingSphere 疾速验证某些性能，集成测试等场景，联合对用户这些应用的场景的思考，内存模式 应运而生。

至此 ShardingSphere 为用户提供了内存模式、单机模式以及集群模式，运行模式在 API 的设计上更容易被用户了解，也更贴合 ShardingSphere 的理论应用场景，同时这 3 种不同的运行模式都能 反对应用 DistSQL 进行分布式数据库服务的疾速搭建和治理。

在 5.0.0 中废除了 governance 配置形式，改为应用 mode 配置不同的运行模式。

mode:
  type: # 运行模式类型 Standalone/Cluster
  repository:
    type: # 长久化类型 不同模式对应不同的实现 Standalone-File,Cluster-ZooKeeper/Etcd
    props: # 不同的长久化类型对应不同的自定义配置
      ...
  overwrite: false # 是否应用本地配置笼罩本地 / 近程配置

接下来和大家具体介绍三种运行模式的概念以及在应用 ShardingSphere 进行业务开发时如何抉择适合的运行模式。

内存模式（Memory）

默认的运行模式，用户无需配置 mode。内存模式下用户无需配置任何长久化组件和策略，无论是本地初始化的配置还是通过 SQL/DistSQL 操作造成的元数据变更，仅在以后过程中失效， 服务重启后配置将会被还原。内存模式实用于集成测试环境，不便开发人员在整合功能测试中集成 ShardingSphere 而 无需清理运行痕迹。

单机模式（Standalone）

ShardingSphere 为单机模式默认提供了本地文件的长久化形式，可能将数据源和规定等元数据信息长久化到本地文件中，而在服务重启的时候，仍然可能 从本地文件中读取配置，放弃元数据和重启之前的版本统一。 单机模式实用于开发工程师在本地疾速搭建 ShardingSphere 的开发环境，进行性能的联调和验证。

单机模式的配置形式如下：

mode:
  type: Standalone
  repository:
    type: File
    props:
      path: ...
  overwrite: false

单机模式默认提供本地文件的长久化形式，默认将配置长久化到用户目录的 .shardingsphere 下，也能够通过配置 path 自定义存储门路。

集群模式（Cluster）

集群模式是 ShardingSphere 倡议的实在部署上线的生产环境必须应用的模式，采纳 JDBC 和 Proxy 混合部署架构也必须应用集群模式。集群模式提供了分布式治理的性能，通过集成独立部署的第三方注册核心，除了可能长久化元数据之外，同时实现了多个实例之间的 数据共享 以及分布式场景下的 状态协调， 也是 ShardingSphere 通过程度扩大来进步计算能力 以及高可用等外围性能的根底。

集群模式的配置形式如下（ZooKeeper 为例）：

mode:
  type: Cluster
  repository:
    type: ZooKeeper
    props:
      namespace: governance_ds
      server-lists: localhost:2181
      retryIntervalMilliseconds: 500
      timeToLiveSeconds: 60
      maxRetries: 3
      operationTimeoutMilliseconds: 500
  overwrite: false

三种运行模式的比照如下，用户能够依照本人的需要进行抉择。

	内存模式	单机模式	集群模式
默认	是	否	否
长久化形式	无	本地文件（默认）	注册核心
实现形式	无	1.File 2. H2 Database（开发中）	1.Zookeeper 2. Etcd
是否须要部署三方组件	否	否	是
是否反对 DistSQL	是	是	是
分布式治理	否	否	是
实用场景	集成测试 / 疾速验证	本地开发 / 性能联调	生产环境 / 混合部署

ShardingSphere 提供的三种运行模式，可能满足用户在测试、开发以及线上部署环境的全副需要，与此同时，借助于 ShardingSphere 弱小的可插拔架构设计，开发者也能够灵便定制各个模式下的长久化形式，打造更适宜本身开发和业务需要的运行模式。同时运行模式也是 SphereEx 中文社区 Governance 兴趣小组长期保护的模块之一，对分布式治理感兴趣的同学，也请关注 SphereEx 中文社区并退出咱们的兴趣小组。

Governance 兴趣小组链接：https://community.sphere-ex.com/t/topic/432

欢送增加社区经理微信（ss_assistant_1）退出交换群，与泛滥 ShardingSphere 爱好者一起交换

关于shardingsphere:ShardingSphere-Mode-模式新起航运行模式详解

作者介绍

分布式治理背景

运行模式的产生

概念与利用场景

结语