雪花算法id不严格递增，因时钟回拨、机器时钟不同步或序列号重置会导致id跳变甚至变小；依赖其做时间排序易出错，强递增需求应改用号段模式或中心化id服务。
为什么雪花算法生成的ID不是严格递增的
雪花算法（Snowflake）生成的 long 类型ID，高位是时间戳，中间是机器ID，低位是序列号。它保证「同一毫秒内多个请求不重复」，但**不保证全局严格递增**——因为时间回拨、多台机器时钟不同步、或同一毫秒内序列号耗尽后跳到下一毫秒再重置序列号，都会导致ID“跳变”甚至“变小”。比如机器A在1712345678000毫秒末生成了1712345678000000002，机器B在1712345678001毫秒初生成了1712345678001000000，看起来递增；但如果B的时钟慢了2ms，它可能还在用1712345678000时间戳生成ID，此时就可能比A的ID小。
常见误用场景：直接拿雪花ID当MySQL主键并依赖ORDER BY id DESC做最新数据排序，在分布式写入+时钟偏差下会漏掉或错序。
- 若需时间趋势大致有序，确保所有节点NTP同步，误差控制在
10ms内 - 若强依赖严格递增，改用数据库自增+号段模式，或引入中心化ID服务（如Leaf）
- 部分封装库（如
Twitter Snowflake原版Java实现）默认不校验时钟回拨，需自行加锁等待或抛异常
Java中用ZooKeeper分配workerId容易踩哪些坑
雪花算法要求每台机器有唯一workerId（通常5位，支持最多32个节点）。用ZooKeeper自动分配看似合理，但实际落地常出问题：
- ZK连接闪断时，应用可能重复注册/获取到相同
workerId，导致ID冲突 —— 必须用临时顺序节点+watch机制，并在创建失败时主动退出而非重试 - 容器化部署下，Pod重启IP可能不变但进程是新的，ZK节点未及时清除，造成“僵尸ID”被复用 —— 需结合
hostname + processId生成ZK路径，或用K8s Downward API注入唯一标识 - 本地开发时没连ZK，硬编码
workerId=1上线后和其他机器撞了 —— 建议启动时校验：若从ZK获取失败，拒绝启动并打印明确错误，而不是fallback到默认值
更轻量的做法：用配置中心（如Nacos）预分配workerId，或启动参数传入（-Dsnowflake.workerId=5），避免运行时依赖外部服务。
立即学习“Java免费学习笔记（深入）”；
如何安全处理时钟回拨
服务器时间被人为调整或NTP校正时，可能导致雪花算法生成重复ID（因为时间戳变小，而序列号未归零）。原生Snowflake对回拨的处理策略直接影响可用性：
- 直接抛异常（如
RuntimeException("Clock moved backwards")）最安全，但业务请求会失败 —— 适合金融等强一致性场景 - 阻塞等待（如循环
Thread.sleep(1)直到时间追上）可能引发雪崩 —— 若回拨10秒，所有线程卡住，QPS归零 - 使用“容忍窗口”：只对小于
5ms的回拨等待，大于则抛异常 —— 需配合监控告警，快速发现时钟异常
推荐方案：
if (timestamp < lastTimestamp) {
long offset = lastTimestamp - timestamp;
if (offset <= 5) {
try {
Thread.sleep(offset << 1);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(e);
}
timestamp = timeGen();
if (timestamp < lastTimestamp) {
throw new RuntimeException("Clock moved backwards more than 5ms");
}
} else {
throw new RuntimeException("Clock moved backwards: " + offset + "ms");
}
}
MyBatis插入时雪花ID被截断成0怎么办
Java里雪花ID是long（64位），但MySQL列类型若定义为INT（32位），插入时会被MySQL静默截断为0或最大值，且无报错。这是线上最隐蔽的ID污染问题之一。
- 检查表结构：
DESCRIBE table_name确认ID字段是BIGINT UNSIGNED（推荐）或至少BIGINT - MyBatis映射中，
<result column="id" property="id" jdbctype="BIGINT"></result>必须显式指定jdbcType，否则某些驱动可能按int推导 - Spring Boot配置
spring.jpa.hibernate.ddl-auto=none，禁用自动建表，避免开发机生成错误schema带到生产
另一个常见点：前端JS处理ID时，Number精度只有53位，超过会丢失低位。传输ID务必用字符串，接口定义中@JsonSerialize(using = ToStringSerializer.class)别省略。
