为什么需要分布式ID生成器？

在分布式系统中，全局唯一ID的生成至关重要。传统单机版自增ID在分布式场景下会面临以下问题：
1. 分库分表时的主键冲突
2. 业务扩展时的ID不连续
3. 高并发场景下的性能瓶颈

笔者在电商系统重构过程中，就曾因订单ID冲突导致严重数据错乱。本文将分享经过实战检验的分布式ID解决方案。

一、主流方案对比分析

方案 | 唯一性 | 有序性 | 吞吐量 | 依赖程度
---|---|---|---|---
UUID | 绝对唯一 | 无序 | 极高 | 无
数据库自增 | 单机唯一 | 绝对有序 | 低 | 强
Redis生成 | 分布式唯一 | 趋势有序 | 高 | 强
Snowflake | 分布式唯一 | 趋势有序 | 极高 | 弱
Leaf框架 | 分布式唯一 | 趋势有序 | 高 | 中等

二、具体实现方案

1. Snowflake算法（推荐）

Twitter开源的经典方案，64位ID结构：java
public class SnowflakeIdWorker {
private final long workerId;
private long sequence = 0L;

public synchronized long nextId() {
    long timestamp = timeGen();
    if (timestamp < lastTimestamp) {
        throw new RuntimeException("时钟回拨");
    }
    if (lastTimestamp == timestamp) {
        sequence = (sequence + 1) & sequenceMask;
        if (sequence == 0) {
            timestamp = tilNextMillis(lastTimestamp);
        }
    } else {
        sequence = 0L;
    }
    lastTimestamp = timestamp;
    return ((timestamp - twepoch) << timestampLeftShift)
            | (workerId << workerIdShift)
            | sequence;
}

}
优点：性能可达10万QPS，ID包含时间信息
缺点：需要解决时钟回拨问题

2. 数据库分段优化方案

针对传统自增ID的改进方案：
sql CREATE TABLE id_generator ( id int NOT NULL AUTO_INCREMENT, biz_tag varchar(64) NOT NULL, max_id bigint NOT NULL, step int NOT NULL, PRIMARY KEY (id) );

Java实现批量获取ID：
java public class DbSegmentIdGenerator { public synchronized List<Long> nextBatch(String bizTag) { // 1. 查询并更新数据库 // 2. 返回[max_id, max_id+step]区间 } }
适用场景：中小型系统，数据库压力可控

3. Redis原子操作方案

利用Redis的INCR命令：java
public class RedisIdGenerator {
private JedisPool jedisPool;

public long nextId(String bizKey) {
    try (Jedis jedis = jedisPool.getResource()) {
        return jedis.incr(bizKey);
    }
}

}
优化技巧：结合Lua脚本实现批量获取

三、生产环境选型建议

根据笔者在金融和电商领域的实践经验：
- 金融交易系统：推荐Snowflake+Zookeeper协调workerId
- 高并发电商：Leaf美团开源方案（结合Snowflake和数据库）
- 物联网设备：可考虑UUIDv7（时间有序版本）

四、避坑指南

1. 时钟回拨问题：Snowflake实现必须增加异常处理
2. 步长设置：数据库方案步长建议设置为QPS的10倍
3. ID长度控制：避免使用128位UUID导致存储浪费

某次大促期间，我们曾因Snowflake的workerId冲突导致ID重复，最终通过Zookeeper分布式锁解决。

结语

分布式ID生成没有银弹，需要根据业务特点选择。建议新系统从Snowflake起步，随着业务增长逐步演进到Leaf等成熟方案。

延伸思考：如何设计支持容灾的多机房ID生成方案？这个问题的答案或许能成为你面试时的亮点。