Java分布式ID生成主流方案有Snowflake、号段模式（如Leaf）和Redis原子操作，分别适用于高并发、强一致性和轻量级场景，选型需根据递增要求、基础设施和监控能力综合判断。
Java中实现分布式ID生成，核心是解决高并发、多节点环境下ID的唯一性、有序性和高性能问题。直接用数据库自增或UUID都不够理想：前者有单点瓶颈和扩展性差，后者无序且存储/索引效率低。主流方案聚焦在“时间+机器标识+序列”组合逻辑上，兼顾可读性、趋势递增与水平扩展能力。
雪花算法（Snowflake）是事实标准
Twitter开源的Snowflake模型被广泛采用，Java生态中如百度UidGenerator、weixin-java-tools中的IdGenerator、以及Apache ShardingSphere内置ID生成器均基于其思想演进。
标准Snowflake结构为64位整数：
- 1位符号位（固定0）
- 41位毫秒级时间戳（约69年可用）
- 10位机器ID（支持1024个节点）
- 12位序列号（每毫秒最多生成4096个ID）
使用时需注意：
- 机器ID不能重复，可通过ZooKeeper分配、配置中心下发或DB注册避免冲突
- 时钟回拨会导致ID重复或服务拒绝，需加入等待、告警或混合逻辑（如美团Leaf的Segment模式兜底）
- Long型ID在MySQL中需用BIGINT UNSIGNED，前端JS处理时注意精度丢失（建议转字符串传输）
数据库号段模式（Segment）适合强一致性场景
以美团Leaf为代表，从DB批量获取一个ID区间（如1–1000），缓存在内存中按需分配，用完再取下一段。优势是ID绝对单调、容灾性强、易于监控。
关键设计点：
- 双Buffer机制：一个号段用尽前异步加载下一个，避免阻塞
- DB表需支持乐观锁更新（如UPDATE … SET max_id = max_id + step WHERE biz_tag = 'order' AND max_id = ?）
- 节点宕机不丢ID，但号段可能浪费（通常可接受）
- 支持动态调整step值，应对流量峰谷
Redis原子操作适合轻量级快速落地
利用INCR或INCRBY命令生成全局递增ID，配合过期时间或命名空间隔离业务类型（如 order:id:202405、user:id:202405）。简单可靠，依赖Redis高可用部署即可。
立即学习“Java免费学习笔记（深入）”；
适用情况：
- QPS不高（万级以内）、对ID长度无硬性要求（Redis返回long，可补零或拼接前缀）
- 已有Redis集群，不想引入新组件
- 需要带业务含义（如前缀+时间+自增）可组合使用INCR与SETNX
注意事项：
- 单实例Redis存在单点风险，建议用Redis Cluster或哨兵模式
- 大量INCR可能影响Redis性能，避免高频小步长调用（如每次+1改成+1000分批）
选型建议：看场景，不盲目追新
没有银弹方案，判断依据主要是：
- 是否要求严格递增：选Segment或Redis
- 是否已有ZK/etcd等协调服务：Snowflake更易管理机器ID
- 是否允许少量ID空洞：Snowflake和Redis都满足，Segment空洞更少
- 是否需要ID携带时间信息：Snowflake原生支持，其他方案需自行拼接
中小团队推荐从Redis方案起步，快速验证；中大型系统建议用UidGenerator（基于Snowflake增强版）或Leaf（Segment模式），并配套埋点监控ID生成延迟、号段余量、时钟偏移等指标。
