问题：MyBatis Plus 雪花算法生成ID冲突如何解决？

Question

在使用 MyBatis Plus 时，部分项目采用内置的雪花算法（SnowFlake）生成唯一主键 ID。但在某些场景下，如多节点部署、系统时间回拨或机器 ID 配置错误，可能会导致生成的 ID 出现重复，从而引发主键冲突异常。这个问题会影响系统的稳定性和数据完整性。那么，在实际开发中，应该如何有效避免 MyBatis Plus 中雪花算法生成 ID 的冲突问题？常见的解决方案包括：调整雪花算法配置、引入第三方增强版雪花算法（如美团 Leaf）、结合数据库自增序列、或切换为其他分布式 ID 生成策略（如 UUID、Redis 自增等）。本文将深入分析该问题的成因，并提供多种可行的解决策略供参考。

Answer 1

一、MyBatis Plus 雪花算法 ID 冲突问题概述

在使用 MyBatis Plus 进行数据库操作时，很多项目默认采用其内置的雪花算法（SnowFlake）来生成唯一主键 ID。雪花算法基于时间戳、机器 ID 和序列号组合生成全局唯一 ID，具有高性能和低延迟的优势。

然而，在分布式系统中，若多个节点部署不当或机器 ID 设置错误，可能导致生成的 ID 出现重复，从而引发主键冲突异常，影响系统的稳定性和数据完整性。

二、雪花算法 ID 冲突的原因分析

雪花算法生成 ID 的结构通常如下：

• 时间戳部分：占用高位，表示生成 ID 时的时间戳。
• 机器 ID 部分：用于区分不同节点，避免相同时间戳下生成重复 ID。
• 序列号部分：同一毫秒内递增的序号，防止并发生成重复 ID。

以下是常见的冲突原因：

冲突原因	描述
多节点部署配置错误	多个节点使用相同的机器 ID，导致生成相同前缀的 ID。
系统时间回拨	服务器时间被同步或调整，导致时间戳倒退，生成重复 ID。
机器 ID 分配混乱	未统一管理机器 ID，出现重复或越界。
高并发场景下的序列号耗尽	单个节点在单位时间内生成太多 ID，导致序列号溢出。

三、解决方案与优化策略

针对上述问题，我们可以从以下几个方向进行优化和改进：

3.1 调整 MyBatis Plus 内置雪花算法配置

可以通过自定义机器 ID 和数据中心 ID 来确保每个节点的唯一性。例如：

        // 设置机器 ID
        IdWorker.setIdOffset(1);
        // 使用默认的雪花算法生成 ID
        Long id = IdWorker.getId();
    

该方法适用于小规模集群，但需要人工维护机器 ID 分配，容易出错。

3.2 引入增强版雪花算法实现

如美团开源的 Leaf 算法，支持动态分配机器 ID，并引入 ZooKeeper 实现协调服务，解决传统雪花算法的缺陷。

Leaf 支持两种模式：

• Segment 模式：预分配一段 ID 区间，减少对中心服务的压力。
• Snowflake 改进模式：通过注册中心管理机器 ID，避免重复。

示例流程图如下：

graph TD
            A[请求获取ID] --> B{是否本地段可用}
            B -->|是| C[返回本地ID]
            B -->|否| D[向ZooKeeper申请新段]
            D --> E[更新本地缓存]
            E --> F[返回新段ID]

3.3 结合数据库自增序列生成 ID

在 MyBatis Plus 中可以将主键类型设置为 IdType.AUTO，由数据库负责生成自增 ID。

优点是简单可靠，缺点是数据库成为瓶颈，不适用于高并发场景。

        @TableId(type = IdType.AUTO)
        private Long id;
    

3.4 切换为其他分布式 ID 生成策略

可考虑以下替代方案：

• UUID：全球唯一标识符，无顺序性，存储空间较大。
• Redis 自增：利用 Redis 的 INCR 命令生成全局唯一 ID，性能高但依赖 Redis 可用性。
• TinyID：滴滴开源的分布式 ID 解决方案，支持多种生成方式。

例如使用 Redis 生成 ID：

        Long id = redisTemplate.opsForValue().increment("global:id");