MyBatis-Plus的雪花ID在高并发下也会撞车？除了workerId，这些坑你踩过吗？-编程实验室

MyBatis-Plus的雪花ID在高并发下也会撞车？除了workerId，这些坑你踩过吗？

分布式系统中唯一ID生成是个经典问题，而雪花算法（Snowflake）因其简单高效成为许多开发者的首选。MyBatis-Plus内置的雪花ID生成器让开发者能够快速上手，但当你把服务部署到Kubernetes集群，面对数百个实例同时生成ID时，可能会发现事情没那么简单——明明配置了不同的workerId，为什么还是出现了ID重复？

1. 雪花算法原理与MyBatis-Plus实现

雪花算法的核心思想是将64位long型数字划分为几个部分：

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

从左到右依次是：

1位符号位（固定为0）
41位时间戳（毫秒级）
5位数据中心ID（dataCenterId）
5位机器ID（workerId）
12位序列号（sequence）

MyBatis-Plus的DefaultIdentifierGenerator默认实现中，关键参数配置如下：

// 默认数据中心ID和机器ID private long dataCenterId = 1L; private long workerId = 1L; // 序列号掩码（12位） private final long sequenceMask = ~(-1L << 12L); // 4095

常见误区：很多开发者认为只要保证workerId不重复就能避免ID冲突，实际上在高并发场景下，至少还有三个关键因素会影响唯一性。

2. 高并发下的四大撞车场景

2.1 时间回拨问题

服务器时钟同步（NTP）可能导致时间回退。当发生时间回拨时，如果回退到之前已经生成过ID的时间段，就可能产生重复ID。

复现条件：

系统时钟被手动调整
NTP服务强制同步时间
虚拟机迁移导致时钟漂移

// MyBatis-Plus的时间回拨处理逻辑 long timestamp = timeGen(); if (timestamp < lastTimestamp) { long offset = lastTimestamp - timestamp; if (offset <= 5) { // 等待时间追平 try { wait(offset << 1); timestamp = timeGen(); } catch (InterruptedException e) { throw new RuntimeException(e); } } else { // 超过最大容忍值，直接抛出异常 throw new RuntimeException( String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", offset)); } }

2.2 序列号耗尽

当单机QPS超过4096/ms时（即12位序列号的最大值），就会发生序列号回绕。虽然这个数字看起来很高，但在以下场景仍可能发生：

批量插入操作
消息队列突发流量
缓存穿透导致大量数据库写入

2.3 容器环境的时间同步问题

在Kubernetes环境中，Pod可能在不同节点间漂移，而节点间的系统时钟可能存在微小差异。当发生以下情况时可能出问题：

Pod A在节点1生成一批ID（使用本地时间）
Pod被调度到节点2
节点2的时钟比节点1慢几毫秒
Pod A在节点2继续生成ID，可能重复使用之前的时间戳

2.4 workerId分配冲突

即使使用随机分配策略（如random.int(1,31)），在以下情况下仍可能冲突：

服务实例数超过workerId最大值（默认31）
随机算法种子相同导致重复
动态扩缩容时新实例分配到已使用的ID

3. 分布式环境下的解决方案

3.1 增强版雪花算法实现

针对标准雪花算法的不足，可以考虑以下改进：

public class EnhancedSnowflake { // 增加时间戳偏移量（可配置） private final long epoch = 1609459200000L; // 2021-01-01 00:00:00 // 增加时钟回拨缓冲 private long lastTimestamp = -1L; private long sequence = 0L; // 使用ThreadLocalRandom避免竞争 private static final ThreadLocalRandom random = ThreadLocalRandom.current(); public synchronized long nextId() { long timestamp = timeGen(); // 处理时间回拨 if (timestamp < lastTimestamp) { long offset = lastTimestamp - timestamp; if (offset <= 5) { try { wait(offset << 1); timestamp = timeGen(); } catch (InterruptedException e) { throw new RuntimeException(e); } } else { // 超过阈值时，使用随机workerId继续运行 workerId = random.nextLong(maxWorkerId); } } // 同一毫秒内序列号递增 if (lastTimestamp == timestamp) { sequence = (sequence + 1) & sequenceMask; if (sequence == 0) { // 序列号耗尽时等待下一毫秒 timestamp = tilNextMillis(lastTimestamp); } } else { // 新毫秒重置序列号 sequence = 0L; } lastTimestamp = timestamp; return ((timestamp - epoch) << timestampLeftShift) | (dataCenterId << dataCenterShift) | (workerId << workerShift) | sequence; } }

3.2 基于ZooKeeper的workerId分配

使用ZooKeeper实现分布式workerId分配确实是个可靠方案，但要注意：

连接管理：确保ZK客户端有重试机制
节点回收：实现临时节点自动清理
故障转移：考虑ZK集群的高可用

public class ZkWorkerIdAssigner { private final CuratorFramework client; private final String namespace; private final int maxWorkerId; public ZkWorkerIdAssigner(String connectString, String namespace, int maxWorkerId) { this.namespace = namespace; this.maxWorkerId = maxWorkerId; this.client = CuratorFrameworkFactory.builder() .connectString(connectString) .retryPolicy(new ExponentialBackoffRetry(1000, 3)) .namespace(namespace) .build(); client.start(); } public int assignWorkerId() throws Exception { // 检查已分配的workerId List<String> children = client.getChildren().forPath("/workers"); Set<Integer> usedIds = children.stream() .map(Integer::parseInt) .collect(Collectors.toSet()); // 寻找可用ID for (int i = 0; i < maxWorkerId; i++) { if (!usedIds.contains(i)) { try { client.create() .creatingParentsIfNeeded() .withMode(CreateMode.EPHEMERAL) .forPath("/workers/" + i); return i; } catch (KeeperException.NodeExistsException e) { continue; } } } throw new IllegalStateException("No available workerId"); } }

3.3 混合ID生成策略

对于超高并发场景，可以考虑组合多种策略：

预生成缓冲池：后台线程预生成ID放入队列
分段ID：不同服务使用不同的ID段
业务前缀：在ID中加入业务标识前缀

-- 数据库表设计示例 CREATE TABLE id_segments ( biz_tag VARCHAR(32) PRIMARY KEY, max_id BIGINT NOT NULL, step INT NOT NULL, description VARCHAR(256), update_time TIMESTAMP ); -- 获取一批ID的存储过程 DELIMITER // CREATE PROCEDURE get_next_ids( IN p_biz_tag VARCHAR(32), IN p_step INT, OUT p_start_id BIGINT, OUT p_end_id BIGINT ) BEGIN DECLARE current_max BIGINT; START TRANSACTION; SELECT max_id INTO current_max FROM id_segments WHERE biz_tag = p_biz_tag FOR UPDATE; IF current_max IS NULL THEN INSERT INTO id_segments(biz_tag, max_id, step, update_time) VALUES(p_biz_tag, p_step, p_step, NOW()); SET p_start_id = 1; SET p_end_id = p_step; ELSE UPDATE id_segments SET max_id = max_id + p_step, update_time = NOW() WHERE biz_tag = p_biz_tag; SET p_start_id = current_max + 1; SET p_end_id = current_max + p_step; END IF; COMMIT; END // DELIMITER ;

4. 生产环境最佳实践

4.1 监控与告警配置

建议监控以下指标：

指标名称	监控方式	告警阈值
ID生成QPS	Prometheus计数器	超过3000/ms
时钟回拨次数	日志分析	任何回拨事件
workerId冲突	ZK节点监控	重复分配事件
序列号耗尽	自定义指标	连续3次等待

# Prometheus监控规则示例 groups: - name: id_generator rules: - alert: HighIDGenerationRate expr: rate(id_generator_requests_total[1m]) > 3000 for: 5m labels: severity: warning annotations: summary: "High ID generation rate detected" description: "Instance {{ $labels.instance }} is generating {{ $value }} IDs per second"

4.2 Kubernetes环境特殊配置

在K8s中部署时，需要特别注意：

Pod反亲和性：避免相同服务的Pod集中在少数节点

affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - my-service topologyKey: kubernetes.io/hostname

时钟同步配置：

containers: - name: my-app image: my-app:latest volumeMounts: - mountPath: /etc/localtime name: host-time readOnly: true volumes: - name: host-time hostPath: path: /etc/localtime

workerId自动分配：

// 使用Downward API获取Pod信息 String podName = System.getenv("POD_NAME"); String podIP = System.getenv("POD_IP"); // 根据Pod信息生成唯一workerId int workerId = Math.abs((podName + podIP).hashCode()) % maxWorkerId;

4.3 压测与验证方法

在实施任何方案前，应该进行充分测试：

时钟回拨测试：

# 模拟时钟回拨（测试环境） sudo date -s "-5 seconds"

并发测试脚本：

import threading import requests def generate_ids(): for _ in range(1000): response = requests.post("http://service/generate-id") print(response.json()['id']) threads = [] for i in range(100): t = threading.Thread(target=generate_ids) threads.append(t) t.start() for t in threads: t.join()

唯一性验证：

-- 检查重复ID SELECT id, COUNT(*) as cnt FROM your_table GROUP BY id HAVING cnt > 1;

在实际项目中，我们曾遇到过一个典型案例：某电商系统在大促期间出现了ID重复问题。事后分析发现，根本原因不是workerId冲突，而是NTP服务在同步时间时造成了毫秒级的时间回退。最终我们采用了组合方案：ZK分配workerId + 本地时钟监控 + 预生成ID缓冲池，系统在大流量下保持了稳定。

MyBatis-Plus的雪花ID在高并发下也会撞车？除了workerId，这些坑你踩过吗？