ShardingSphere主键生成器

ShardingSphere 提供了多种分布式主键生成器（Key Generator），以满足不同场景下的全局唯一 ID 需求。根据其实现机制和版本演进，主要分为以下几类：

---

⚙️ 一、内置基础生成器

1. UUID

   • 特点：生成 32 位字符串（如 550e8400-e29b-41d4-a716-446655440000），全球唯一。

   • 缺点：无序、存储空间大，可能导致数据库索引碎片化，影响插入性能156。

   • 适用场景：对主键性能要求不高的简单应用。

   • 配置示例（YAML）：

     yaml

     keyGenerators:  
       uu-id-gen:  
         type: UUID  

2. Snowflake（雪花算法）

   • 特点：生成 64 位长整型（如 123456789012345678），结构包含：

     • 1 位符号位（恒为 0）

     • 41 位时间戳（从 2016-11-01 起，支持约 69 年）

     • 10 位工作进程 ID（需集群中唯一）

     • 12 位序列号（单毫秒内最多 4096 个 ID）178。

   • 优点：有序递增，适合数据库索引优化。

   • 时钟回拨处理：支持设置 max-tolerate-time-difference-milliseconds 阈值，超限则报错，否则等待时钟同步18。

   • 适用场景：默认推荐策略，适用于高并发分库分表场景。

---

🔗 二、Leaf 集成方案（需额外依赖）

ShardingSphere 5.x 后通过扩展集成美团 Leaf 框架，提供两种模式：

1. Leaf-Segment（号段模式）

   • 原理：预分配号段（如 1~1000 存入内存），耗尽后从数据库重新申请。

   • 依赖：需配置数据库表存储号段信息35。

   • 优点：高性能、低延迟。

   • 配置示例：

     properties

     # leaf.properties  
     leaf.key=order_id  
     leaf.jdbc.url=jdbc:mysql://localhost:3306/db  
     leaf.jdbc.username=root  
     leaf.jdbc.password=123456  

2. Leaf-Snowflake（雪花增强模式）

   • 原理：基于雪花算法，但通过 ZooKeeper 管理工作进程 ID，避免手动配置。

   • 依赖：需 ZooKeeper 服务35。

   • 适用场景：需自动化管理 Worker ID 的大规模集群。

---

🧩 三、扩展算法（ShardingSphere 5.x+）

新增以下三种策略，需在配置中显式声明：

1. NanoID

   • 类似 UUID，但长度更短（21 位字符串），仍存在无序性问题5。

2. CosId

   • 通用分布式 ID 生成器接口，可适配多种底层实现。

3. CosId-Snowflake

   • 基于 CosId 接口的雪花算法优化版，支持更灵活的位分配5。

---

🛠️ 四、自定义生成器

用户可实现 ShardingKeyGenerator 接口，并通过 SPI 机制 注入：

1. 实现接口：

   java

    

   public class MyKeyGenerator implements ShardingKeyGenerator {  
     @Override  
     public Comparable<?> generateKey() {  
         // 如 Redis 自增 ID、自定义算法等  
         return atomicLong.incrementAndGet();  
     }  
     @Override  
     public String getType() {  
         return "MY_KEY";  
     }  
   }  

2. 注册 SPI：
   在 META-INF/services/org.apache.shardingsphere.spi.keygen.ShardingKeyGenerator 文件中添加实现类全路径46。

---

📊 对比总结与选型建议

类型	ID 格式	有序性	依赖	适用场景
Snowflake (默认)	64 位 Long	✅ 递增	无	高并发分库分表（推荐）
Leaf-Segment	Long	✅ 递增	数据库	高吞吐、低延迟场景
Leaf-Snowflake	64 位 Long	✅ 递增	ZooKeeper	大规模集群自动化管理
UUID/NanoID	字符串	❌ 无序	无	简单应用，非性能敏感场景
自定义	任意	可定制	无/外部服务	特殊业务需求（如结合 Redis）

💡 最佳实践：

• 优先选择 Snowflake：满足大多数场景的性能和有序性要求18。

• 避免主动拼接主键：插入数据时不要为主键赋值，否则会覆盖生成策略5。

• 分片键与主键分离：若使用 Snowflake 的 ID 作分片键，需配置 max-vibration-offset 避免数据倾斜5。

具体配置详见 ShardingSphere 官方文档15。