一、真实场景：双11订单号重复，数据被覆盖

2023年双11，我们团队负责的电商系统在高峰期出现订单号重复。排查发现，MySQL自增ID在分库分表后，多个库同时插入导致ID冲突。更严重的是，重复ID覆盖了已有订单数据，直接造成2000+订单丢失。事后复盘，问题出在ID生成方案选型上——我们用了最简单的auto_increment，没考虑分布式场景。

这次事故后，我花了2周时间调研并压测了4种主流分布式ID方案：Snowflake、美团Leaf、百度UidGenerator、Redis自增。下面直接上对比结果和代码。

二、方案对比：4种ID生成器核心差异

测试环境：PHP 8.3.2，Laravel 11.0，MySQL 8.0.35，Redis 7.2.4，ZooKeeper 3.8.3，服务器4核8G。

三、方案1：Snowflake算法（PHP实现）

Snowflake是Twitter开源的分布式ID算法，核心思想：64位long型ID = 1位符号位 + 41位时间戳 + 10位机器ID + 12位序列号。

我踩过的坑：时钟回拨。某次NTP同步导致时间回拨200ms，直接生成重复ID。下面给出带时钟回拨保护的实现。

 self::MAX_WORKER_ID) {
            throw new InvalidArgumentException("Worker ID must be between 0 and " . self::MAX_WORKER_ID);
        }
        $this->workerId = $workerId;
    }

    public function nextId(): int
    {
        $timestamp = $this->getTimestamp();

        // 时钟回拨处理
        if ($timestamp < $this->lastTimestamp) {
            $diff = $this->lastTimestamp - $timestamp;
            if ($diff > self::MAX_BACKWARD_MS) {
                throw new RuntimeException("Clock moved backwards more than " . self::MAX_BACKWARD_MS . "ms");
            }
            // 等待时间追上
            usleep($diff * 1000);
            $timestamp = $this->getTimestamp();
            if ($timestamp < $this->lastTimestamp) {
                throw new RuntimeException("Clock still behind after waiting");
            }
        }

        if ($timestamp === $this->lastTimestamp) {
            $this->sequence = ($this->sequence + 1) & self::MAX_SEQUENCE;
            if ($this->sequence === 0) {
                // 序列号用完，等待下一毫秒
                while ($timestamp <= $this->lastTimestamp) {
                    $timestamp = $this->getTimestamp();
                }
            }
        } else {
            $this->sequence = 0;
        }

        $this->lastTimestamp = $timestamp;

        return (($timestamp - self::EPOCH) << self::TIMESTAMP_SHIFT)
            | ($this->workerId << self::WORKER_ID_SHIFT)
            | $this->sequence;
    }

    private function getTimestamp(): int
    {
        return (int)(microtime(true) * 1000);
    }
}

// 使用示例
$snowflake = new Snowflake(1);
echo $snowflake->nextId() . PHP_EOL;
?>

压测结果：单机QPS约40万，ID趋势递增，无重复。但时钟回拨保护会阻塞线程，极端情况可能影响性能。

四、方案2：美团Leaf（Segment模式）

美团Leaf是美团开源的分布式ID方案，支持Segment模式和Snowflake模式。Segment模式预取ID段到内存，减少数据库压力。

我部署Leaf时遇到的最大坑：ZooKeeper连接超时导致服务不可用。后来改用MySQL作为协调者。

# Leaf配置文件 leaf.properties（Leaf 1.5.0）
# Segment模式
leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.segment.url=jdbc:mysql://localhost:3306/leaf?useSSL=false&serverTimezone=UTC
leaf.segment.username=root
leaf.segment.password=123456

# Snowflake模式（可选）
leaf.snowflake.enable=false
leaf.snowflake.zk.address=localhost:2181
leaf.snowflake.port=2181

-- Leaf 数据库表结构（MySQL 8.0.35）
CREATE TABLE `leaf_alloc` (
  `biz_tag` varchar(128) NOT NULL DEFAULT '',
  `max_id` bigint(20) NOT NULL DEFAULT '1',
  `step` int(11) NOT NULL,
  `description` varchar(256) DEFAULT NULL,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 初始化业务
INSERT INTO leaf_alloc(biz_tag, max_id, step) VALUES('order', 1, 1000);

baseUrl = $baseUrl;
    }

    public function nextId(string $bizTag): int
    {
        if ($this->currentId >= $this->maxId) {
            $this->fetchSegment($bizTag);
        }
        return $this->currentId++;
    }

    private function fetchSegment(string $bizTag): void
    {
        $url = $this->baseUrl . '/api/segment/get/' . $bizTag;
        $response = file_get_contents($url);
        $data = json_decode($response, true);
        if (!$data || !isset($data['id'])) {
            throw new RuntimeException("Failed to fetch segment from Leaf server");
        }
        $this->currentId = $data['id'];
        $this->maxId = $data['id'] + 1000; // step=1000
    }
}

// 使用示例
$leaf = new LeafClient();
echo $leaf->nextId('order') . PHP_EOL;
?>

压测结果：单机QPS约10万，ID严格递增，无重复。但依赖Leaf Server，多了一层网络开销。

五、方案3：百度UidGenerator

百度UidGenerator基于Snowflake，但用MySQL管理workerId分配，内置时钟回拨处理。我选它是因为它解决了Snowflake的workerId手动配置问题。

# UidGenerator配置（uid-generator 1.1.6）
# application.yml
uid:
  timeBits: 28
  workerBits: 22
  seqBits: 13
  epochStr: "2023-01-01"
  workerIdAssigner: com.baidu.fsg.uid.worker.DisposableWorkerIdAssigner
  cachedQueueSize: 8192

-- UidGenerator 数据库表
CREATE TABLE `worker_node` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `host_name` varchar(64) NOT NULL,
  `port` varchar(32) NOT NULL,
  `type` int(11) NOT NULL,
  `launch_date` date NOT NULL,
  `modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

baseUrl = $baseUrl;
    }

    public function nextId(): int
    {
        $url = $this->baseUrl . '/uid/nextId';
        $response = file_get_contents($url);
        $data = json_decode($response, true);
        if (!$data || !isset($data['id'])) {
            throw new RuntimeException("Failed to get ID from UidGenerator");
        }
        return (int)$data['id'];
    }

    public function parseId(int $uid): array
    {
        $url = $this->baseUrl . '/uid/parseId?uid=' . $uid;
        $response = file_get_contents($url);
        return json_decode($response, true);
    }
}

// 使用示例
$uid = new UidClient();
$id = $uid->nextId();
echo "ID: $id\n";
print_r($uid->parseId($id));
?>

压测结果：单机QPS约30万，ID趋势递增，无重复。但需要维护MySQL表，部署稍复杂。

六、方案4：Redis自增ID

最简单的方案：利用Redis的INCR命令。适合ID长度不固定的场景，但QPS受限于Redis单线程。

redis = $redis;
        $this->prefix = $prefix;
    }

    public function nextId(string $bizTag): int
    {
        $key = $this->prefix . $bizTag;
        return $this->redis->incr($key);
    }

    public function nextBatchIds(string $bizTag, int $batchSize): array
    {
        $key = $this->prefix . $bizTag;
        $this->redis->multi();
        $this->redis->incrBy($key, $batchSize);
        $this->redis->get($key);
        $result = $this->redis->exec();
        $maxId = (int)$result[1];
        $ids = [];
        for ($i = $maxId - $batchSize + 1; $i <= $maxId; $i++) {
            $ids[] = $i;
        }
        return $ids;
    }
}

// 使用示例
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$generator = new RedisIdGenerator($redis);
echo $generator->nextId('order') . PHP_EOL;
print_r($generator->nextBatchIds('order', 10));
?>

压测结果：单机QPS约5万，ID严格递增。但Redis宕机后ID会丢失连续性，且无法保证全局唯一（如果Redis集群分片）。

七、效果数据：压测对比

测试工具：Apache Bench (ab)，并发100，请求10万次。

结论：Snowflake性能最好，但需要处理时钟回拨；Leaf和UidGenerator适合需要严格递增的场景；Redis自增适合低并发场景。

八、避坑指南

以下是我实际踩过的坑，每个都付出了真金白银的代价：

• 时钟回拨：Snowflake必须实现回拨保护。我遇到过NTP同步导致时间回拨500ms，生成重复ID。解决方案：等待或抛出异常。
• Worker ID冲突：手动配置Worker ID容易重复。建议用ZooKeeper或MySQL自动分配。
• Leaf Server单点：Leaf Server宕机导致ID生成中断。必须部署多节点+负载均衡。
• Redis持久化：Redis宕机重启后ID从1开始，导致重复。必须开启AOF持久化，并设置合理的备份策略。
• ID长度溢出：PHP的int类型在32位系统上只能表示到21亿。必须用64位PHP或字符串存储。
• 性能瓶颈：Redis自增在QPS超过5万时，网络IO成为瓶颈。建议用pipeline批量获取。

九、最终推荐

根据我的经验：

• 高并发（QPS>10万）：选Snowflake，自己实现时钟回拨保护。
• 严格递增+高可用：选美团Leaf（Segment模式），部署多节点。
• 中等并发（QPS<5万）：选Redis自增，简单可靠。
• 不想自己维护：选百度UidGenerator，开箱即用。

我们最终选择了Snowflake + ZooKeeper自动分配Worker ID的方案，线上运行6个月，生成ID超过10亿，零重复。