分布式系统全局 ID 的生成

拼搏现实的明天。 2022-12-17 10:57 164阅读 0赞

## 1.概念 ##

在分布式系统设计中，经常需要一个全局唯一的ID来标识一条数据，比如订单表，商品表的主键ID。这个ID往往能影响到数据存储、索引和查询等操作的效率。因此这个全局唯一的ID对系统的可用性和性能至关重要

## 2.特点 ##

1.  全局唯一性
2.  趋势递增。目前MySQL主流引擎是InnoDB，而InnoDB使用的是聚集索引，即本质是B-tree的数据结构来存储索引数据，所以使用有序的主键可以保证写入性能
3.  单调递增。如事务版本号、IM增量消息、排序等特殊需求会用到
4.  信息安全。
5.  高可用性
6.  分片支持。可以控制ShardingId。比如某一个用户的文章要放在同一个分片内，这样查询效率高，修改也容易
7.  长度适中

## 3.常见生成方案 ##

#### 3.1 UUID ####

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符

例：550e8400-e29b-41d4-a716-446655440000

优点：

*  性能非常高：本地生成，API调用方便，没有网络消耗

缺点：

*  存储成本高：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用
 *  信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露
 *  ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用。UUID不是趋势递增的，而现阶段主流的数据库主键索引都是选用的B+树索引，对于无序长度过长的主键插入效率比较低

#### 3.2 数据库 ####

如MySQL，利用给字段设置auto\_increment\_increment和auto\_increment\_offset就可以保证ID自增

优点：

*  非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护
 *  ID号单调自增，可以实现一些对ID有特殊要求的业务

缺点：

*  强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号
 *  ID发号性能瓶颈限制在单台MySQL的读写性能

#### 3.3 Redis ####

主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID，可以用Redis的原子操作 INCR和INCRBY来实现

比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加

优点：

*  不依赖于数据库，灵活方便，且性能优于数据库
 *  数字ID天然排序，对分页或者需要排序的结果很有帮助

缺点：

*  引入Redis，增加系统复杂度
 *  需要编码和配置的工作量比较大

#### 3.4 zookeeper ####

zookeeper主要通过其znode数据版本来生成序列号，可以生成32位和64位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。

很少会使用zookeeper来生成唯一ID。主要是由于需要依赖zookeeper，并且是多步调用API，如果在竞争较大的情况下，需要考虑使用分布式锁。因此，性能在高并发的分布式环境下，也不甚理想。

#### 3.5 雪花算法 ####

这种方案大致来说是一种以划分命名空间来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，  
比如在snowflake中的64-bit分别表示如下图所示：  
![在这里插入图片描述][20201023150610638.png_pic_center]  
1-bit的时间可以表示（1L<<41）/(1000L360024\*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的

优点：

*  毫秒数在高位，自增序列在低位，整个ID都是趋势递增的
 *  不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的
 *  可以根据自身业务特性分配bit位，非常灵活

缺点：

*  强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态

[20201023150610638.png_pic_center]: /images/20221122/3ed2128f062a4410ab0ef478b6d920e7.png