谈谈常用的分布式 ID 设计方案

常用的分布式 ID 设计方案有以下几种：

1. 数据库自增 ID：

   • 优点：简单，天然有序。

   • 缺点：并发性不好，数据库写压力大，数据库故障后不可使用，存在数量泄露风险。

   • 优化方案：

     • 数据库水平拆分，设置不同的初始值和相同的自增步长。

     • 基于数据库的号段模式，即预先在数据库中生成一段 ID 号段，应用启动时获取该号段，当本地的号段快用完时，再去数据库获取新的号段。

2. UUID：

   • 优点：简单易用，无需依赖中心化服务，生成速度快，适用于无需严格顺序的场景。

   • 缺点：UUID 比较长，占用存储空间大，不保证 ID 生成的有序性，可能会影响数据库索引效率。

3. Snowflake 雪花算法：

   • 优点：高性能、分布式环境下无冲突，易于水平扩展，适用于大规模分布式系统，生成的 ID 是全局唯一的，且可以保证高效地生成，不依赖于集中式服务。

   • 缺点：时间戳位有一定的时钟回拨问题，需要预先分配机器 ID，可能会导致机器数目限制。

   • 变种与改进：

     • MongoDB ObjectId：使用 12 字节存储时间戳、机器 ID、进程 ID 和计数器，适用于非数值型 ID 场景。

     • 美团的 Leaf：支持号段模式和 Snowflake 模式，适应不同业务需求。

     • 百度的 UidGenerator：通过环形缓冲（Ring Buffer）提升吞吐量，解决高并发下性能问题。

4. 基于 Redis 的 incr 命令：

   • 优点 ：利用 Redis 的单线程模型来保证分布式 ID 的唯一性，而 INCR 命令则保证了分布式 ID 的有序性。

   • 实现方法：

     • 初始化数据，设置分布式 ID 的初始结构。

     • 对于单机模式下的 Redis，直接使用 INCR 命令即可保证有序性。

     • 对于集群模式下的 Redis，给每个节点设置不同的初始偏移量，并使用 INCRBY 命令指定集群中所有节点数量的步长来保证全局唯一性。

5. Google 的 Spanner：

   • 优点：通过 TrueTime API 来保证全球时间的一致性，从而生成全局唯一的 ID。

   • 缺点：实现复杂，需要依赖于 Google 的基础设施，对于一般的分布式系统来说成本较高。

在选择分布式 ID 生成策略时，需要考虑性能要求、ID 有序性、存储与传输、分布式架构等因素。