分布式ID生成有几种方案？-蒲公英云

分布式ID生成有几种方案？

港控/mmm° 2024-02-05 14:28 111阅读 0赞

分布式ID生成方案有多种，以下是其中几种常见的方案：

时间戳方案：使用服务器的时间戳作为ID，时间戳自增或根据当前时间生成。这种方案简单易行，但存在时间同步问题，可能导致不同节点生成的ID冲突。
UUID方案：使用UUID（Universally Unique Identifier）作为ID，UUID是一种全局唯一标识符，由随机数生成器生成。这种方案简单易用，但UUID长度较长，可能会占用较多的存储空间。
分布式ID生成器：使用分布式ID生成器，如Snowflake、Ratchet、AtomicLong等，这些工具在多个节点上生成全局唯一的ID。这些工具通常会记录生成ID的顺序和时间戳等信息，以解决时间同步问题。
数据库自增ID方案：在数据库中设置一个自增的字段作为ID，每个节点都会在本地记录当前自增ID的最大值，并在生成ID时递增。这种方案简单易用，但需要数据库支持自增功能，并且可能会存在性能问题。
自定义方案：根据实际需求，可以自定义分布式ID生成方案。例如，可以使用基于时间戳和机器ID的组合，或者使用基于某种哈希算法的方案等。
分布式ID的特性
唯一性：确保生成的ID是全网唯一的。
有序递增性：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。高可用性：确保任何时候都能正确的生成ID。
带时间：ID里面包含时间，一眼扫过去就知道哪天的交易。
分布式ID生成方案
UUID
算法的核心思想是结合机器的网卡、当地时间、一个随记数来生成UUID。优点：本地生成，生成简单，性能好，没有高可用风险
缺点：长度过长，存储冗余，且无序不可读，查询效率低
数据库自增ID
使用数据库的id自增策略，如 MySQL 的 auto_increment。并且可以使用两台数据库分别设置不同步长，生成不重复ID的策略来实现高可用。
优点：数据库生成的ID绝对有序，高可用实现方式简单缺点：需要独立部署数据库实例，成本高，有性能瓶颈
批量生成ID

一次按需批量生成多个ID，每次生成都需要访问数据库，将数据库修改为最大的ID值，并在内存中记录当前值及最大值。
优点：避免了每次生成ID都要访问数据库并带来压力，提高性能缺点：属于本地生成策略，存在单点故障，服务重启造成ID不连续

Redis生成ID
Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。
优点：不依赖于数据库，灵活方便，且性能优于数据库；数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度；需要编码和配置的工作量比较大。
考虑到单节点的性能瓶颈，可以使用 Redis 集群来获取更高的吞吐量。假如一个集群中有5台
Redis。可以初始化每台 Redis 的值分别是1, 2, 3, 4, 5，然后步长都是 5。
Twitter的snowﬂake算法（重点）
Twitter 利用 zookeeper 实现了一个全局ID生成的服务 Snowﬂake

如上图的所示，Twitter 的 Snowﬂake 算法由下面几部分组成：
1位符号位：
由于 long 类型在 java 中带符号的，最高位为符号位，正数为 0，负数为 1，且实际系统中所使用的ID一般都是正数，所以最高位为 0。
41位时间戳（毫秒级）：
需要注意的是此处的 41 位时间戳并非存储当前时间的时间戳，而是存储时间戳的差值（当前时间戳 - 起始时间戳），这里的起始时间戳一般是ID生成器开始使用的时间戳，由程序来指定，所以41
位毫秒时间戳最多可以使用。
10位数据机器位：

包括5位数据标识位和5位机器标识位，这10位决定了分布式系统中最多可以部署
s个节点。超过这个数量，生成的ID就有可能会冲突。
12位毫秒内的序列：
这 12 位计数支持每个节点每毫秒（同一台机器，同一时刻）最多生成加起来刚好64位，为一个Long型。
优点：高性能，低延迟，按时间有序，一般不会造成ID碰撞缺点：需要独立的开发和部署，依赖于机器的时钟

百度UidGenerator
UidGenerator是百度开源的分布式ID生成器，基于于snowﬂake算法的实现，看起来感觉还行。不过，国内开源的项目维护性真是担忧。
美团Leaf
Leaf 是美团开源的分布式ID生成器，能保证全局唯一性、趋势递增、单调递增、信息安全，里面也提到了几种分布式方案的对比，但也需要依赖关系数据库、Zookeeper等中间件。

需要注意的是，无论采用哪种方案，都需要考虑时间同步、冲突解决、性能和扩展性等问题。在实际应用中，需要根据具体情况选择合适的方案。