Snowflake 通过时间戳、机器ID、序列号三段式位运算生成唯一递增ID，避免锁且解决高并发重复问题；需校验workerId（0-1023）、datacenterId（0-31）及时间戳不回拨。
为什么直接用 System.currentTimeMillis() 不行
时间戳本身不唯一，高并发下毫秒内可能产生多个请求；单纯加锁又严重拖慢吞吐。Snowflake 的核心思路是把 ID 拆成时间、机器、序列三段，靠位运算拼接，既避免锁，又保证单调递增和全局唯一。
常见错误现象：Invalid timestamp: 0 或生成 ID 突然变小——多半是系统时钟回拨没处理；还有人把 workerId 写死为 0，集群里全节点 ID 都撞了。
- 时间戳用的是毫秒级，但 Snowflake 默认预留 41 位，最多支撑到 2106 年，够用但别误算成秒级
-
workerId和datacenterId必须在进程启动时确定且全局不重复，不能靠随机或 UUID 生成——它们要能被快速比较和路由 - 序列号（
sequence）每毫秒清零重计，一旦该毫秒内超 4096 次调用，会阻塞等待下一毫秒，这是设计取舍，不是 bug
Java 实现里最常漏掉的两个校验
开源实现（比如 Twitter 原版或百度的 uid-generator）都带校验，但手写时容易跳过。缺了它们，ID 可能错得毫无征兆。
典型问题：本地测试全 ok，上线后某台机器生成的 ID 总是高位为 0，查日志发现 workerId 被初始化成了负数——因为没校验输入范围。
立即学习“Java免费学习笔记（深入）”；
- 必须校验
workerId∈ [0, 1023]（10 位）、datacenterId∈ [0, 31]（5 位），超出就抛IllegalArgumentException - 必须校验传入的
timestamp不小于上次生成时间，否则直接拒绝——时钟回拨超过 5ms 就该报警，而不是静默重试
示例片段：
if (workerId > MAX_WORKER_ID || workerId < 0) {
throw new IllegalArgumentException("workerId can't be greater than " + MAX_WORKER_ID + " or less than 0");
}怎么安全地分配 workerId 而不依赖 ZooKeeper
小规模部署（≤10 台机器）根本没必要上 ZK 或 etcd。硬编码或配置文件最稳，但得防人为填错；自动分配看似省事，反而容易引发 ID 冲突。
真实踩坑：用 Redis INCR 分配 workerId，结果 Redis 故障导致所有新实例拿到 0，ID 大面积重复。
- 推荐方式：启动时读取环境变量
WORKER_ID或 JVM 参数-DworkerId=5，没设就直接报错退出，不默认兜底 - 如果必须动态，可用文件锁（
FileChannel.lock()）在共享路径下争抢编号，但得确保路径挂载一致、权限可写 - 千万别用 IP 哈希或主机名哈希——容器重启、IP 变更、多网卡都会让哈希值漂移
生成的 ID 作为 MySQL 主键时要注意什么
MySQL 默认主键是 BIGINT UNSIGNED，而 Java 的 long 是有符号的，最大值 2⁶³−1 ≈ 9.2×10¹⁸；Snowflake ID 最大是 2⁶⁴−1，但实际使用中只要不超过 2⁶³−1 就不会溢出。
关键陷阱：SELECT * FROM table WHERE id = 12345678901234567890 在某些 JDBC 驱动版本下会变成负数——因为客户端解析超长数字时丢了精度。
- 数据库字段必须定义为
BIGINT UNSIGNED，不能只写BIGINT - JDBC URL 加上
useSSL=false&serverTimezone=UTC&tinyInt1isBit=false，避免旧驱动把 long 当 tinyint 解析 - MyBatis 中用
<result column="id" property="id" javaType="java.lang.Long"/>显式声明类型，别依赖自动映射
事情说清了就结束
