分布式id生成方案，如何实现分库分表

啥也不懂的派大星

已于 2024-07-07 16:51:42 修改

阅读量1k

点赞数

分类专栏：面试题-数据库文章标签：分布式中间件数据库

于 2023-02-07 14:35:10 首次发布

本文链接：https://blog.csdn.net/zwb_dzw/article/details/128918216

版权

面试题-数据库专栏收录该内容

13 篇文章 1 订阅

订阅专栏

分布式id生成方案？

1、UUID

1 ，当前日期和时间时间戳

2 ，时钟序列。计数器

3 ，全局唯一的 IEEE 机器识别号，如果有网卡，从网卡 MAC 地址获得，没有网卡以其他方式获得。

优点：代码简单，性能好（本地生成，没有网络消耗），保证唯一（相对而言，重复概率极低可以忽略）

缺点：

每次生成的 ID 都是无序的，而且不是全数字，且无法保证趋势递增。

UUID 生成的是字符串，字符串存储性能差，查询效率慢，写的时候由于不能产生顺序的append 操作，需要进行insert操作，导致频繁的页分裂，这种操作在记录占用空间比较大的情况下，性能下降比较大，还会增加读取磁盘次数UUID 长度过长，不适用于存储，耗费数据库性能。

ID 无一定业务含义，可读性差。

有信息安全问题，有可能泄露 mac 地址。

2、数据库自增序列

单机模式：

优点：

实现简单，依靠数据库即可，成本小。

ID 数字化，单调自增，满足数据库存储和查询性能。

具有一定的业务可读性。（结合业务 code ）

缺点：

强依赖 DB ，存在单点问题，如果数据库宕机，则业务不可用。

DB 生成 ID 性能有限，单点数据库压力大，无法扛高并发场景。

信息安全问题，比如暴露订单量， url 查询改一下 id 查到别人的订单。

数据库高可用：多主模式做负载，基于序列的起始值和步长设置，不同的初始值，相同的步长，步长大于节点数。

优点：

解决了 ID 生成的单点问题，同时平衡了负载。

缺点：

系统扩容困难：系统定义好步长之后，增加机器之后调整步长困难。

数据库压力大：每次获取一个 ID 都必须读写一次数据库。

主从同步的时候：电商下单 -> 支付 insert master db select数据，因为数据同步延迟导致查不到这个数据。加 cache( 不是最好的解决方式 ) 数据要求比较严谨的话查 master 主库。

3、雪花算法

生成一个64bit 的整性数字。

第一位符号位固定为 0 ， 41 位时间戳， 10 位 workId ， 12位序列号，位数可以有不同实现。

雪花算法是一种生成分布式全局唯一 ID 的算法，它会得到一个 64 位长度的 long 类型数据。

其中这 64 位的数据，由 4 个部分组成。

第一个 bit 位是符号位，因为 id 不会是负数，所以它一般是 0；

接着用 41 个 bit 位来表示毫秒单位的时间戳；

再用 10 个 bit 位来表示工作机器 id；

最后 12 个 bit 位表示递增的序列号；

把这 64 个 bit 位拼接成一个 long 类型的数字，就是雪花算法的实现。

优点：

每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳（依赖workId的实现）。
时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的。
能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高。

缺点：

强依赖于机器时钟，如果时钟回拨，会导致重复的ID生成，所以一般基于此的算法发现时钟回拨，都会抛异常处理，阻止ID生成，这可能导致服务不可用。

4、基于redis、zk、mongodb等中间件生成

Redis生成ID

定义：利用Redis的原子操作（如INCR和INCRBY命令）生成唯一的递增数值作为ID。
优点：
- 高性能，支持高并发环境。
- 简单且易于扩展。
缺点：
- 依赖于外部服务（Redis），需要管理和维护额外的基础设施。
网络依赖性：高度依赖网络。

Zookeeper生成ID

定义：通过Zookeeper的znode数据版本来生成序列号，可以生成32位或64位的数据版本号。
优点：
- 利用Zookeeper的分布式特性，保证ID的全局唯一性。
缺点：
- 依赖Zookeeper，系统复杂度增加。
- 在高并发环境下性能可能不理想。
网络依赖性：高度依赖网络。

5、数据库号段模式 Leaf-segment

定义：从数据库批量获取自增ID号段，然后在本地缓存并生成ID，直到号段用完再向数据库申请新的号段。美团的。

核心字段：biz_tag，max_id，step。

biz_tag 用来区分业务， max_id 表示该 biz_tag 目前所被分配的 ID 号段的最大值， step表示每次分配的号段长度，原来每次获取 ID 都要访问数据库，现在只需要把 Step 设置的足够合理如 1000，那么现在可以在 1000 个 ID 用完之后再去访问数据库。

优点：

减少对数据库的频繁访问，提高性能。

扩张灵活，性能强能够撑起大部分业务场景。

ID 号码是趋势递增的，满足数据库存储和查询性能要求。

可用性高，即使 ID 生成服务器不可用，也能够使得业务在短时间内可用，为排查问题争取时间。

缺点：

仍然存在单点故障风险（可通过集群模式解决）。
如果服务在用完ID段之前下线或重启，可能导致ID浪费。
可能存在多个节点同时请求ID区间的情况，依赖DB。
对网络的依赖相对较低，只在申请新的ID段时需要访问数据库。

双buffer ：将获取一个号段的方式优化成获取两个号段，在一个号段用完之后不用立马去更新号段，还有一个缓存号段备用，这样能够有效解决这种冲突问题，而且采用双 buffer的方式，在当前号段消耗了10 % 的时候就去检查下一个号段有没有准备好，如果没有准备好就去更新下一个号段，当当前号段用完了就切换到下一个已经缓存好的号段去使用，同时在下一个号段消耗到 10 % 的时候，又去检测下一个号段有没有准备好，如此往复。

缺点：

segment号段长度是固定的，业务量大时可能会频繁更新号段，因为原本分配的号段会一下用完如果号段长度设置的过长，但凡缓存中有号段没有消耗完，其他节点重新获取的号段与之前相比可能跨度会很大，动态调整 Step。