数据库主键 ID 生成策略

前言：　

　系统唯一ID是我们在设计一个系统的时候常常会遇见的问题，下面介绍一些常见的ID生成策略。

• Sequence ID
• UUID
• GUID
• COMB
• Snowflake

　　最开始的自增ID为了实现分库分别的需求，会在自增的前提下，使用不同起点，但需要做数据库拓展时，极其麻烦。 比如刚开始时，我们设计某个系统的数据库时，这个数据库中会有10个表，那么我们对于每个表的内容都需要不同的ID我们就可以使用不同不长自增的形式，比如，第一张表的是1、11、21、31。。。 第二张表是2、12、22、32。。。 第三张表是3、13、23、33。。。 第十张表就是10、20、30。。。 但是这样的问题就是，如果有一天我发现这个系统的10张表已经不够用了，我想要再添加一张表，那么这时的主键应该怎么分配呢？ 另外，如果对于多个数据库的数据希望合并，但是对于这种简单的生成ID方式，重复的可能性很大，所以几乎一定会发生重复这种情况。 显然，如果使用之前的方法的可扩展性会比较差。

　　相比自增ID，UUID生成唯一主键更加方便（数据量非常大的情况下，存在重复的可能），但由于UUID的无序性，性能不如自增ID，字符串储存，储存空间大，查询效率低。关键：使用uuid的缺点是查询效率低啊！

　　COMB相对于UUID，增加了生成ID的有序性，插入与查询效率都有所提高。 这篇文章有简单的分析。

COMB数据类型的基本设计思路是这样的：既然UniqueIdentifier数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留UniqueIdentifier的前10个字节，用后6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与UniqueIdentifier组合起来，在保留UniqueIdentifier的唯一性的同时增加了有序性

　**　Sonwflake是Twitter主键生成策略，可以看做是COMB的一种改进**，用64位的长整型代替128位的字符串。ID构成：第一位0 + 41位的时间前缀 + 10位的节点标识 + 12位的sequence避免并发的数字。

第一部分：Sequence ID

　　数据库自增长序列或字段，最常见的方式。由数据库维护，数据库唯一。

优点：

1. 简单，代码方便，性能可以接受。
2. 数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

1. 不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
2. 在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
3. 在性能达不到要求的情况下，比较难于扩展。
4. 如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
5. 分表分库的时候会有麻烦。

优化方案：

　　　针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。

比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

第二部分：UUID

　　npm 管理 www.npmjs.com/package/uuid

　 　常见的方式,128位。可以利用数据库也可以利用程序生成，一般来说全球唯一。

　　UUID是128位的全局唯一标识符，通常由32字节的字符串表示。它可以保证时间和空间的唯一性，也称为GUID，全称为：UUID ―― Universally Unique IDentifier，Python 中叫 UUID。

　　它通过MAC地址、时间戳、命名空间、随机数、伪随机数来保证生成ID的唯一性。

　　 UUID主要有五个算法，也就是五种方法来实现。

（1）、 uuid1()

――基于时间戳。由MAC地址、当前时间戳、随机数生成。可以保证全球范围内的唯一性，但MAC的使用同时带来安全性问题，局域网中可以使用IP来代替MAC。

（2）、uuid2()

――基于分布式计算环境DCE（Python中没有这个函数）。算法与uuid1相同，不同的是把时间戳的前4位置换为POSIX的UID。实际中很少用到该方法。

(3)、uuid3()

――基于名字的MD5散列值。通过计算名字和命名空间的MD5散列值得到，保证了同一命名空间中不同名字的唯一性，和不同命名空间的唯一性，但同一命名空间的同一名字生成相同的uuid。

（4）、uuid4()

――基于随机数。由伪随机数得到，有一定的重复概率，该概率可以计算出来。

（5）、uuid5()

――基于名字的SHA-1散列值。算法与uuid3相同，不同的是使用 Secure Hash Algorithm 1 算法。

优点：

1. 简单，代码方便。
2. 全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点：

1. 没有排序，无法保证趋势递增。
2. UUID往往是使用字符串存储，查询的效率比较低。
3. 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
4. 传输数据量大
5. 不可读。

优化方案：

1. 为了解决UUID不可读，可以使用UUID to Int64的方法。

第三部分： GUID

GUID：是微软对UUID这个标准的实现。UUID还有其它各种实现，不止GUID一种。优缺点同UUID。

第四部分： COMB

　 COMB（combine）型是数据库特有的一种设计思想，可以理解为一种改进的GUID，它通过组合GUID和系统时间，以使其在索引和检索事有更优的性能。

　　数据库中没有COMB类型，它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中设计出来的。
　　COMB数据类型的基本设计思路是这样的：既然UniqueIdentifier数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么我们能不能通过组合的方式，保留UniqueIdentifier的前10个字节，用后6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与UniqueIdentifier组合起来，在保留UniqueIdentifier的唯一性的同时增加了有序性，以此来提高索引效率。

优点：

1. 解决UUID无序的问题，在其主键生成方式中提供了Comb算法(combined guid/timestamp)。保留GUID的10个字节，用另6个字节表示GUID生成的时间(DateTime)。
2. 性能优于UUID。

第五部分： Twitter的snowflake算法

　snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。snowflake算法可以根据自身项目的需要进行一定的修改。比如估算未来的数据中心个数，每个数据中心的机器数以及统一毫秒可以能的并发数来调整在算法中所需要的bit数。

优点：

1. 不依赖于数据库，灵活方便，且性能优于数据库。
2. ID按照时间在单机上是递增的。

缺点：

1. 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。

六、使用

这个使用起来是真的方便：

npm install uuid --save

然后就可以使用啦！

  const uuidv1 = require(‘uuid/v1‘);
  console.log(‘随机uuid字符串‘, uuidv1());

这样，我们就可以打印出来uuid字符串了。 每次的都不一样。

本作品采用《CC 协议》，转载必须注明作者和本文链接