ShardingSphere 入门教程之一

发表于 更新于 阅读次数： 评论数： 本文字数： 6.6k 阅读时长 ≈ 6 分钟

大纲

前言

学习资源

基础核心理论

CAP 理论

CAP 的概念：

  • CAP 定理（CAP theorem）又被称作布鲁尔定理（Brewer’s theorem），是加州大学伯克利分校的计算机科学家埃里克・布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想。对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。 在一个 分布式系统中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

    • C 一致性（Consistency）：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果
    • A 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应 （不是错误和超时的响应）
    • P 分区容忍性（Partition Tolerance）：当出现网络分区后 （可能是丢包，也可能是连接中断，还可能是拥塞），系统能够继续 “履行职责”

CAP 的特点：

  • 在实际设计过程中，每个系统不可能只处理一种数据，而是包含多种类型的数据，有的数据必须选择 CP，有的数据必须选择 AP，分布式系统理论上不可能选择 CA 架构。

    • CP：如下图所示，为了保证一致性，当发生分区现象后，N1 节点上的数据已经更新到 y，但由于 N1 和 N2 之间的复制通道中断，数据 y 无法同步到 N2，N2 节点上的数据还是 x。这时客户端 C 访问 N2 时，N2 需要返回 Error，提示客户端 C "系统现在发生了错误"， 这种处理方式 违背了可用性（Availability）的要求，因此这里 CAP 三者只能满足 CP。

    • AP：如下图所示，为了保证可用性，当发生分区现象后，N1 节点上的数据已经更新到 y，但由于 N1 和 N2 之间的复制通道中断，数据 y 无法同步到 N2，N2 节点上的数据还是 x。这时客户端 C 访问 N2 时，N2 将当前自己拥有的数据 x 返回给客户端 C 了，而实际上当前最新的数据已经是 y 了，这就 不满足一致性（Consistency）的要求了，因此这里 CAP 三者只能满足 AP。注意：这里 N2 节点返回 x，虽然不是一个 “正确” 的结果，但是一个 “合理” 的结果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据而已。

CAP 理论与 BASE 理论的关系

BASE 理论是对 CAP 定理中 "一致性与可用性权衡" 的实践总结，是在大规模分布式系统工程经验基础上演化而来的。它并非否定一致性，而是在无法满足强一致性（Strong Consistency）时，为 CAP 中偏向 AP 的系统提供的一种补充思路。BASE 的核心理念是：在业务可接受的前提下牺牲强一致性，以提高系统可用性和伸缩性；允许数据在短时间内不一致，但保证系统最终会达到一致状态（Eventual Consistency）。

BASE 理论

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论。BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。BASE 是以下三个原则的缩写：

  • (1) Basically Available（基本可用）

    • 系统保证基本可用性，即系统在大部分时间内是可用的，但不一定保证在所有情况下都能正常处理所有请求。例如，在部分系统节点发生故障时，系统仍然能够提供服务，但可能会有部分功能受限或性能下降。

  • (2) Soft State（软状态）

    • 软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

  • (3) Eventually Consistent（最终一致性）

    • 系统保证在没有新的更新操作后，经过一段时间后，所有数据副本最终会达到一致状态。这与 ACID 中的强一致性（即在事务完成后，所有数据立即一致）不同，最终一致性允许在短期内存在不一致，但最终会达到一致。

BASE 理论总结

  • BASE 理论常用于 NoSQL 数据库和大规模分布式系统中，如 Cassandra、Amazon DynamoDB 等。这些系统通过放松一致性要求，以换取更高的可用性和分区容忍度，适应大规模、分布式环境中的高并发和高性能需求。
  • 总的来说，BASE 理论在分布式系统中强调的是可用性和扩展性，通过接受短期的不一致性来实现系统的高可用性和高性能。

高性能数据库架构

互联网业务兴起之后，海量用户加上海量数据的特点，单个数据库服务器已经难以满足业务需要，必须考虑数据库集群的方式来提升性能。高性能数据库集群的第一种方式是 "读写分离"，第二种方式是 "数据库分片"。

读写分离架构

读写分离的基本原理：将数据库读和写操作分散到不同的节点上，下面是其基本架构图：

读写分离的基本实现：

  • 主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能得到极大的改善。
  • 读写分离是 根据 SQL 语义的分析，将读操作和写操作分别路由至主库与从库。
  • 通过 一主多从 的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。
  • 使用 多主多从 的方式，不但能够提升系统的吞吐量，还能够提升系统的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。
  • 下图展示了根据业务需要，将用户表的写操作和读操分别路由到不同的数据库的方案：

读写分离的局限（约束）：

  • CAP 理论中的 一致性（Consistency）在 MySQL 实践中是不可能完美实现的，在 MySQL 主从数据复制的过程中，主节点 N1 和从节点 N2 的数据并不完全一致（强一致性）。
  • 即使无法做到 强一致性，但应用可以采用适合的方式达到 最终一致性。具有特点如下：
    • 基本可用（Basically Available）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
    • 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
    • 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

数据库分片架构

读写分离的存在问题：

  • 读写分离分散了数据库读写操作的压力，但没有分散数据库的存储压力，为了满足业务数据存储的需求，就需要 将存储分散到多台数据库服务器上（即数据分片）。

数据分片是指什么：

  • 将存放在单一数据库中的数据分散地存放至多个数据库或表中，以达到提升性能瓶颈以及可用性的效果。数据分片的有效手段是对关系型数据库进行 分库和分表。数据分片的拆分方式又分为 垂直分片和水平分片。

垂直分片

垂直分片又称为垂直拆分，有两种实现方式：垂直分表、垂直分库。垂直分片可以缓解数据量和访问量带来的问题，但无法根治；如果垂直分片之后，表中的数据量依然超过单节点所能承载的阈值，则需要通过水平分片来进一步处理。

垂直分表

  • 垂直分表是将表中某些不常用的列，或者是占了大量空间的列拆分出去。

  • 假设有一个婚恋网站，用户在筛选其他用户的时候，主要是用 age 和 sex 两个字段进行查询，而 nickname 和 description 两个字段主要用于展示，一般不会在业务查询中用到。description 本身又比较长，因此可以将这两个字段独立到另外一张表中，这样在查询 age 和 sex 时，就能带来一定的性能提升。

  • 垂直分表引入的复杂性主要体现在表操作的数量要增加。例如，原来只要一次查询就可以获取 name、age、sex、nickname、description，现在需要两次查询，一次查询获取 name、age、sex，另外一次查询获取 nickname、description。

垂直分库
  • 按照业务拆分数据库称为垂直分库（也叫业务分库），它的核心理念是专库专用。 在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将读写压力分散至不同的数据库。

  • 下图展示了根据业务需要，将用户表和订单表垂直分库到不同的数据库的方案：

水平分片

  • 水平分片又称为横向拆分，有两种实现方式：水平分表、水平分库。
水平分表
  • 水平分表：将同一张表的数据按某种规则（如 ID 范围或哈希）拆分到多张结构相同的表中，每张表只存储部分数据，以减小单表的数据量、提升查询和写入性能。水平分表适合表行数特别大的表。

  • 单表拆分为多表后，即使多个表仍在同一台数据库服务器上，也能显著提升性能；如果此方式在性能方面能够满足业务需求，则无需进一步进行垂直分库，因为跨库操作会增加系统复杂度（比如跨库事务处理）。只有当单表拆分为多表后，单机性能仍然不足时，才需要将多个表分散在多台数据库服务器中。
水平分库

与垂直分库按业务拆分不同，水平分库是根据某个字段（或几个字段）通过特定规则，将数据分散到多个库或表中，每个分片只存储部分数据。例如，可按主键分片：偶数主键记录放入 0 库（或表），奇数主键记录放入 1 库（或表），如下图所示。

阿里巴巴 Java 开发手册

  • 单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
  • 说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

读写分离和数据分片架构

下图展现了将读写分离与数据分片结合使用时，应用程序与数据库集群之间的复杂拓扑关系。

读写分离和数据分片实现

读写分离和数据分片的具体实现方式一般有两种： 程序代码封装和中间件封装。

常见解决方案

  • MyCat（中间件封装），支持读写分离、数据分片等。
  • Apache ShardingSphere（程序代码封装和中间件封装），支持读写分离、数据分片等。

程序代码封装

程序代码封装是指在项目代码中抽象一个 数据访问层（或中间层封装），实现读写操作分离和数据库服务器连接的管理。以读写分离为例，其基本架构如下图所示：

中间件封装

中间件封装指的是 独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。对于业务服务器来说，访问中间件和访问数据库没有区别，在业务服务器看来，中间件就像是一个数据库服务器。以读写分离为例，其基本架构如下图所示：

ShardingSphere 简介

ShardingSphere 简单介绍

Apache ShardingSphere 是一款分布式的数据库生态系统，可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。Apache ShardingSphere 设计哲学为 Database Plus，旨在构建异构数据库上层的标准和生态。它关注如何充分合理地利用数据库的计算和存储能力，而并非实现一个全新的数据库。它站在数据库的上层视角，关注它们之间的协作多于数据库自身。

总结

Apache ShardingSphere 由 JDBC、Proxy 和 Sidecar（规划中）这 3 款既能够独立部署，又支持混合部署配合使用的产品组成。

ShardingSphere 发展历史

  • (1) Sharding-JDBC 诞生（2015）

    • 最初由当当网开源。
    • 作为 轻量级、无代理的 Client 层分库分表组件。
    • 提供核心能力：读写分离、水平分库分表、SQL 路由、结果归并。
    • 在当时主要对标 MyCat、TDDL 等数据中间件。
    • 特点：不需要独立部署，直接嵌入应用端架构，使用最轻量。

  • (2) Sharding-Proxy 与 Sharding-Sidecar 的提出（2018）

    • 随着业务体量扩大，Client 模式无法覆盖所有场景，ShardingSphere 开始扩展为体系化中间件：
    • Sharding-Proxy
      • 类似 MySQL/PostgreSQL 协议代理的独立中间件。
      • 支持多种语言客户端接入（因其协议兼容）。
      • 适用于不可修改应用代码或不想侵入业务的场景。
    • Sharding-Sidecar（未大规模推广）
      • 面向云原生 Service Mesh（与 Istio 类似）。
      • 数据层的 Sidecar 代理模式，但复杂度较高，因此未大规模应用。
      • 这一步标志着 ShardingSphere 从 “一个轻量库” 向 “分布式数据库中间件体系” 演进。

  • (3) 加入 Apache 基金会（2018.11）

    • 项目进入 Apache 孵化器（Apache Incubator）。
    • 完成交接后开始进行体系化重构。
    • 这使得项目由 “企业内部开源” 转变为 “社区驱动的开源生态”。

  • (4) 正式成为 Apache 顶级项目（2020.04）

    • 项目更名为 Apache ShardingSphere。
    • 提出 “Database Plus” 的理念，强调增强数据库能力而非替代数据库。

  • (5) ShardingSphere 逐步扩展覆盖数据库增强领域的关键能力（2020 – 2024）

    • 分库分表（核心）
      • 标准分片策略
      • 确定性路由、广播表、绑定表
      • 自动生成主键（Snowflake 等）
    • 读写分离
      • 多主多从
      • 基于流量 / 标签路由
    • 分布式事务
      • 支持 XA
      • BASE 柔性事务（Seata 整合）
    • 高级 SQL 能力
      • SQL 重写、结果归并
      • Transparent SQL —— 业务无需改写 SQL
    • 数据加密
      • 列级加密、脱敏
    • 影子库（压测）
      • 增强链路压测能力
    • 生态整合
      • Spring Boot Starter
      • Kubernetes / Operator
      • ElasticJob、Seata、MySQL、PG、TiDB 等生态适配

  • (6) 向数据库增强平台演进（2024 – 2025）

    • ShardingSphere 不再只是读写分离 / 分库分表的中间件，而是演化为 Database Plus Platform（数据库增强平台）
    • 目标是：
      • 为任意数据库提供增强能力
      • 不改变数据库、不改变 SQL
      • 通过 “规则 + 引擎” 提供扩展
    • 包括：
      • 数据治理（Governance）
      • SQL 审计、流量治理
      • 分布式场景增强
      • 灾备、限流
      • 热点数据治理等

ShardingSphere 生态项目

ShardingSphere 开源的分布式数据库生态项目：

  • ShardingSphere-JDBC：

    • Client 端框架
    • 继续增强分库分表、读写分离、影子库压测、分布式事务等能力

  • ShardingSphere-Proxy：

    • 数据库协议代理
    • 支持 MySQL / PostgreSQL 协议
    • 多语言应用均可通过 Proxy 访问分布式数据库能力

  • ShardingSphere-Sidecar（未大规模推广）：

    • 面向云原生架构、借鉴 Service Mesh 思路的 “数据库 Mesh” 方案
    • 由于复杂度较高，因此未大规模应用，虽然未成为主流，但有部分 PoC（概念验证）版本

ShardingSphere-JDBC

ShardingSphere-JDBC 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。它使用客户端直连数据库，以 Jar 包形式提供服务，无需额外部署和依赖，可理解为增强版的 JDBC 驱动，完全兼容 JDBC 和各种 ORM 框架。

  • 适用于任何基于 JDBC 的 ORM 框架，如：JPA、Hibernate、Mybatis、Spring JDBC Template 或直接使用 JDBC；
  • 支持任何第三方的数据库连接池，如：C3P0、DBCP、Druid、BoneCP、HikariCP 等；
  • 支持任意实现了 JDBC 规范的数据库，目前支持 MySQL、PostgreSQL、Oracle、SQLServer 以及任何可使用 JDBC 访问的数据库。

ShardingSphere-Proxy

ShardingSphere-Proxy 定位为透明化的 数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前提供 MySQL 和 PostgreSQL 版本，它可以使用任何兼容 MySQL / PostgreSQL 协议的访问客户端（如：MySQL Command Client、MySQL Workbench、Navicat 等）操作数据，对 DBA 更加友好。

  • 对应用程序完全透明，可直接当作 MySQL / PostgreSQL 使用；
  • 适用于任何兼容 MySQL / PostgreSQL 协议的客户端。