Apache ShardingSphere 内置的分片算法( 自动分片算法、标准分片算法、复合分片算法和 Hint 分片算法)

csdn_tom_168

于 2025-07-08 00:14:41 发布

阅读量268

点赞数 15

CC 4.0 BY-SA版权

分类专栏： Apache ShardingSphere 文章标签： apache ShardingSphere 学习

本文链接：https://blog.youkuaiyun.com/csdn_tom_168/article/details/149159998

Apache ShardingSphere 专栏收录该内容

15 篇文章

订阅专栏

Apache ShardingSphere 内置的分片算法按照其设计目标和适用场景，确实可以清晰地划分为以下四大类型：自动分片算法、标准分片算法、复合分片算法和 Hint 分片算法

1. 自动分片算法 (`AUTO_SHARDING`)

定位： 自动化分片，无需手动指定分片键和算法。
核心思想： 基于分布式主键生成器（如 Snowflake, CosId) 的前缀或特定规则自动计算分片位置。
代表算法：
- MOD (取模)：根据主键值直接取模分片。
- HASH_MOD (哈希取模)：先对主键哈希，再取模分片。
- VOLUME_RANGE (基于容量的范围分片)：根据预设的 range-lower 和 range-upper 范围分片。
- BOUNDARY_RANGE (基于边界的分片)：根据预设的精确边界值列表分片。
- AUTO_INTERVAL (自动时间段分片)：最常用。根据时间戳主键自动按固定时间间隔分片（如按天、月、年）。
优势：
- 配置极简： 只需定义分片数量和主键生成策略。
- 自动路由： 开发无需关心分片键值如何计算路由。
劣势：
- 灵活性受限： 路由规则完全绑定主键生成策略。
- 查询依赖： 非主键查询（尤其是非分片键）可能引发全路由。
适用场景： 主键为分布式ID且查询主要依赖主键的场景。

YAML 配置示例 (AUTO_INTERVAL):

shardingAlgorithms:
  table_auto_interval:
    type: AUTO_INTERVAL
    props:
      datetime-lower: '2023-01-01 00:00:00' # 时间下限
      datetime-upper: '2025-12-31 00:00:00' # 时间上限
      sharding-seconds: 86400 # 分片间隔秒数 (86400秒=1天)

2. 标准分片算法 (`STANDARD`)

定位： 最常用、最核心的分片算法类型，处理单一分片键的精确分片和范围分片。
核心思想： 开发者显式配置分片键和路由算法。
算法组合：
- StandardShardingAlgorithm (必需)： 处理 = 和 IN 查询。
- RangeShardingAlgorithm (可选)： 处理 BETWEEN, >, < 等范围查询。
代表算法：
- INLINE：最推荐。基于 Groovy 表达式的轻量级算法 (如 ds${order_id % 8})。
- MOD / HASH_MOD：简单或哈希取模。
- INTERVAL：强大。处理时间范围分片，可自动处理日期格式化、溢出。
- CLASS_BASED：终极灵活。自定义实现分片逻辑。
优势：
- 精准控制： 自由选择分片键和算法。
- 高性能： 路由计算高效。
- 组合能力强： 精确+范围算法覆盖大部分场景。
适用场景： 绝大多数需要明确分片键的场景。

YAML 配置示例 (INLINE + 范围支持):

shardingAlgorithms:
  user_id_hash_mod: # 标准精确分片 (MOD)
    type: MOD
    props:
      sharding-count: 4 # 分成4片
tables:
  t_user:
    actualDataNodes: ds${0..3}.t_user
    databaseStrategy:
      standard:
        shardingColumn: user_id
        shardingAlgorithmName: user_id_hash_mod

3. 复合分片算法 (`COMPLEX`)

定位： 处理多个分片键组合路由的复杂场景。
核心思想： 使用多个分片键共同决定数据位置。
代表算法：
- CLASS_BASED：唯一选择。必须自定义实现 ComplexKeysShardingAlgorithm 接口。
工作流程：
1. 获取 SQL 中涉及的多个分片键的值 (ShardingValue)。
2. 开发者编写逻辑，综合所有分片键值计算目标数据源/表。
优势： 解决单分片键无法满足的复杂业务路由需求。
劣势：
- 开发复杂： 需手写路由逻辑。
- 维护成本高： 业务变更需同步修改算法。
适用场景： 需要同时按多个维度分片（如 tenant_id + region_id）。

YAML 配置示例：

shardingAlgorithms:
  custom_complex_algo: # 指向自定义实现类
    type: CLASS_BASED
    props:
      strategy: COMPLEX
      algorithmClassName: com.example.algos.MyComplexShardingAlgo
tables:
  t_biz_data:
    databaseStrategy:
      complex:
        shardingColumns: tenant_id, region_code # 指定两个分片键
        shardingAlgorithmName: custom_complex_algo

4. Hint 分片算法 (`HINT`)

定位： 强制路由，完全绕过 SQL 解析，通过编程方式指定分片位置。
核心思想： 使用 HintManager API 在代码中硬编码分片信息。
代表算法：
- CLASS_BASED：必须自定义实现 HintShardingAlgorithm 接口。
- VALUE：简单值匹配（较少用）。
使用步骤：
1. 实现 HintShardingAlgorithm 接口，定义如何解析 Hint 值。
2. 代码中通过 HintManager 设置分片值或直接分片目标。
优势：
- 绝对控制： 无视 SQL 内容强制路由。
- 解决极端场景： 如无分片键的查询、跨分片复杂操作。
劣势：
- 完全侵入式： 业务代码需耦合 ShardingSphere API。
- 破坏透明性： 背离分库分表对应用透明的初衷。
适用场景：
- 执行跨分片笛卡尔积查询（如全量统计）。
- 数据迁移/修复工具。
- 特殊管理操作。

Java 代码示例：

try (HintManager hintManager = HintManager.getInstance()) {
  // 强制设置分库分表值
  hintManager.addDatabaseShardingValue("t_order", 1); // 路由到库分片值=1
  hintManager.addTableShardingValue("t_order", 2);    // 路由到表分片值=2
  // 执行SQL (SELECT * FROM t_order) 将被强制路由到 ds1.t_order_2
  orderDao.selectAll();
}

总结对比表

算法类型	核心特点	分片键数量	主要算法实现	适用场景	侵入性
自动分片算法	主键自动路由	0 (隐式)	`AUTO_INTERVAL`, `MOD`, `VOLUME`	主键驱动型业务	低 (配置)
标准分片算法	单分片键 + 精确/范围路由	1	`INLINE`, `INTERVAL`, `CLASS`	绝大多数常规分片	中 (配置键)
复合分片算法	多分片键组合路由	≥2	`CLASS_BASED` (自定义)	多维度分片	高 (需编码)
Hint分片算法	编程强制指定路由	N/A	`CLASS_BASED` (自定义)	特殊操作、无分片键查询	极高 (API)