分布式ID生成方案

分布式ID（Distributed ID）是指在分布式系统环境下，由多个服务节点协同或者独立生成的、能够确保全局唯一性的数据标识符。

在单机数据库时代，我们通常使用数据库的自增主键（Auto Increment Primary Key） 来为数据赋予一个唯一的ID。这种方式简单可靠。

但是，在分布式系统（如微服务架构）中，问题变得复杂：

分库分表：数据被水平拆分到多个数据库或表中。如果每个库/表都使用自己的自增ID，很快就会产生重复的ID，无法保证全局唯一。
性能瓶颈：如果所有ID都从一个中央数据库的自增序列获取，这个数据库就会成为系统的单点瓶颈和潜在故障点，无法满足高并发场景。
安全性与连续性：直接暴露的自增ID很容易被猜出业务量（例如，通过ID大小推测订单数量），存在安全隐患。同时，自增ID通常是连续的，在某些场景下不希望被猜测。

一个理想的分布式ID生成方案，应该尽可能满足以下要求：

分布式ID的解决方案非常多，可以根据其核心思想分为以下几大类：

a) 数据库号段模式（Segment）
这是对传统数据库自增的一种优化，也是许多开源框架（如Leaf）的核心思想。

原理：不再是每次取一个ID，而是由一台数据库服务器预先分配一个号段（比如1~1000）。业务服务将整个号段加载到内存中，然后在本地方派发ID。当号段用尽后，再向数据库申请新的号段。
优点：大大减少了数据库的访问次数，性能极高。可用性可以通过数据库主从来保证。
缺点：依然依赖数据库，数据库宕机会导致整个系统不可用（除非有备用节点）。

b) 数据库自增ID + 多实例模式

原理：设置多台数据库实例，每台实例的起始值和步长不同。
- 实例1：auto_increment_offset = 1, auto_increment_increment = 2 -> ID: 1, 3, 5, 7…
- 实例2：auto_increment_offset = 2, auto_increment_increment = 2 -> ID: 2, 4, 6, 8…
优点：解决了单点性能问题。
缺点：非常不推荐！ 扩展性极差，一旦需要新增实例，重新设置步长和偏移量会非常麻烦，容易出错。

原理：生成一个36位的字符串（如 550e8400-e29b-41d4-a716-446655440000），标准格式包含32个16进制数字，分为五段。其本身可以通过MAC地址、时间戳、随机数等保证全局唯一。
优点：生成简单，本地生成无网络消耗，绝对唯一。
缺点：
- 作为数据库主键性能差：字符串过长，且无序，会导致B+树索引频繁分裂，严重影响写入性能。
- 不满足趋势递增。
- 无可读性。

这是目前业界最流行、应用最广泛的方案。Twitter开源（但未维护）的分布式ID生成算法。

原理：生成一个64位的Long型数字ID，其结构如下：
- 1位符号位：固定为0。
- 41位时间戳（毫秒）：可以持续使用约69年。
- 10位工作机器ID（Datacenter ID + Worker ID）：最多支持1024个节点。
- 12位序列号：每毫秒内最多生成4096个ID。
工作流程：在同一毫秒内，如果某个节点收到请求，它会增加其序列号。如果序列号用完，就阻塞到下一毫秒再继续生成。
优点：
- 高性能：本地生成，无需网络开销。
- 趋势递增：ID是数值型且随时间增大。
- 灵活：可根据业务调整各部分的位数。
缺点：
- 时钟回拨问题：如果机器时钟发生回退（例如被NTP同步纠正），可能会导致生成重复ID。这是最大的挑战，需要在算法中解决（如等待时钟追上来、记录最后生成时间戳等）。
- 需要维护工作机器ID：需要保证每个节点的Worker ID不重复，通常需要通过ZK/Etcd或数据库来分配。

变种：各大公司对Snowflake的改进，如百度的UidGenerator、美团的Leaf（支持号段模式和snowflake模式）。

直接使用成熟的开源解决方案，省去自研的麻烦。