写点什么

ShardingSphere Mode 模式新起航:运行模式详解

作者:SphereEx
  • 2021 年 12 月 27 日
  • 本文字数:2681 字

    阅读完需:约 9 分钟

在 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
复制代码

三种运行模式的对比如下,用户可以按照自己的需求进行选择。

结语

ShardingSphere 提供的三种运行模式,能够满足用户在测试、开发以及线上部署环境的全部需求,与此同时,借助于 ShardingSphere 强大的可插拔架构设计,开发者也可以灵活定制各个模式下的持久化方式,打造更适合自身开发和业务需求的运行模式。 同时运行模式也是 SphereEx 中文社区 Governance 兴趣小组长期维护的模块之一,对分布式治理感兴趣的同学,也请关注 SphereEx 中文社区并加入我们的兴趣小组。


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


欢迎添加社区经理微信(ss_assistant_1)加入交流群,与众多 ShardingSphere 爱好者一同交流


用户头像

SphereEx

关注

还未添加个人签名 2020.11.09 加入

SphereEx,让数据和应用连接更简单

评论

发布
暂无评论
ShardingSphere Mode 模式新起航:运行模式详解